Re: 2.6.8-rc1-np1

From: Nick Piggin (nickpiggin_at_yahoo.com.au)
Date: 07/17/04

  • Next message: William Lee Irwin III: "Re: [RFC] Lock free fd lookup" 
    Date:	Sat, 17 Jul 2004 19:25:58 +1000
To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>

    Felipe Alfaro Solana wrote:
    > On Sat, 2004-07-17 at 15:23 +1000, Nick Piggin wrote:
    >
    >
    >>Scheduler behaviour is generally pretty good now so I've increased the
    >>timeslice size to see how far I can push it. Some workloads really demand
    >>small timeslices though, so I've added /proc/sys/kernel/base_timeslice.
    >>If you have any problems with the default, please report it to me, and
    >>check if lowering this value helps.
    >
    >
    > On my 700Mhz Pentium III Mobile laptop, I feel that 256ms is too high
    > for the system to keep interactive when a CPU hog is running. For

    Yeah, it is probably a bit too large here too. A burst of activity
    from X can cause xmms to skip slightly. Probably 128 or 64 would
    be a decent default.

    > example, running "while true; do a=2; done" makes the system pretty
    > sluggish with the default timeslice. This is noticeable while dragging
    > windows around (the movement is jerky and doesn't feel smooth).
    > Decreasing the timeslie to 50ms, or even better, 25ms, makes the system
    > behave much much better, although it will decrease throughput
    > considerably, I guess.
    >

    It usually isn't too bad for desktops, but is more important on
    systems with more CPUs and bigger caches.

    On this dual P3 with 256K L2 cache, a make -j8 vmlinux uses
    162.16user 15.43system, ~150ctxsw/s with base_timeslice = 10000
    163.88user 16.16system, ~300ctxsw/s with base_timeslice = 32
    192.65user 17.27system, ~1300ctxsw/s with base_timeslice = 1

    So you come to the point of diminishing returns very quickly, and
    32 or even 16 or 8 are probably fine values for a desktop system
    and worth the small cost for CPU intensive tasks.
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: William Lee Irwin III: "Re: [RFC] Lock free fd lookup"

    Relevant Pages

    • Re: [patch] sched-2.6.0-test1-G6, interactivity changes
      ... > CPU speed and cache size. ... and no doubt the smaller the timeslice the worse it is. ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: [SHED] Questions.
      ... > should be back on the cpu pretty quick. ... Once a task exhausts its timeslice, it cannot run until all other tasks ... > that a task that gets preempted should have a guaranteed time on the cpu ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)
    • Re: Poor PostgreSQL scaling on Linux 2.6.25-rc5 (vs 2.6.22)
      ... 10ms, then if your ssh only needs average of 5ms of CPU time per second, ... CPU time per second, then it has to wait for 2 seconds anyway to be run ... regardless of whether the timeslice was 10ms or 20ms. ... Just because tpc-c runs are set up so the number of server threads ...
      (Linux-Kernel)
    • Re: [PATCH] Minor scheduler fix to get rid of skipping in xmms
      ... >> time required to derive useful benefit depends on the cpu type but can be ... > gets the cache misses into cache faster) ... > speeds climb that the clock time is close to being consistant? ... that varying timeslice according to clock speed sounding like a good idea, ...
      (Linux-Kernel)
    • Re: [PATCH] O17int
      ... > the cpu off to non-gui task who's going to use his full 100 ms slice, ... I wish I could get mm3 running so I could evaluate those interactivity ... I can't imagine any interactivity regressions that are worse than this ... the speed of the machine and use that to determine the min timeslice? ...
      (Linux-Kernel)