2.6.8-rc1-np1
http://www.kerneltrap.org/~npiggin/2.6.8-rc1-np1/
Now that I finally a highmem system, I've been able to make some progress on the memory management chaneges. Still needs more work though. Feedback would be nice if anyone is testing.
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.
Things are working alright on my desktop with base_timeslice at 10000 which corresponds to around 15-20 *second* timeslices, however I don't do much fancy, and it does have the problem of a newly forked CPU hog possibly causing a long freeze (fixable by using a smaller value for the first timeslice).
The -mm version of my patch also removes that kernel's dried gastropod simulator for 2GB+ systems.
Quoted 5 lines · Nick Piggin
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 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.
For light to low worloads, the default of 256ms seems acceptable, though.
PS: I will test -np1 on my 2Ghz PIV machine very soon.
Quoted 10 lines · Felipe Alfaro Solana
Quoted 5 lines · Nick Piggin
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.
Quoted 2 lines
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.
Quoted 7 lines
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.
Quoted 11 lines · Nick Piggin
Quoted 10 lines · Felipe Alfaro Solana
Quoted 5 lines · Nick Piggin
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.
Quoted 7 lines
Quoted 2 lines
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.
Feels fine here on 3GHz P4 (HT system on i875 with dual channel memory, striped raid ST38013AS HDD's). xmms haven't skipped yet (X reniced to -10) and desktop switching is quick. First time typing might be a bit sluggish in gnome-terminal, but second/third char is fine, and vim seems to load fast enough. All this is with a 'make -j24' for kernel (yeah, not really that realistic, but thought I should give it a go) and make -j4 for xorg-x11 going. A few load values is:
load average: 26.72, 15.99, 7.35
load average: 27.93, 19.48, 9.52
load average: 28.02, 19.64, 9.63
load average: 26.01, 19.36, 9.59
base_timeslice is 256 btw ...
Quoted 8 lines
Quoted 7 lines
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.
Cannot say I can really feel this test. That with 'make -j4' for X have load:
load average: 2.74, 4.45, 5.98
where the last is still high from the make -j24.
Quoted 16 lines
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 withbase_timeslice= 32 192.65user 17.27system, ~1300ctxsw/s withbase_timeslice= 1So 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Signature · 1 line
Martin Schlemmer
Quoted 12 lines · Nick Piggin
http://www.kerneltrap.org/~npiggin/2.6.8-rc1-np1/
Now that I finally a highmem system, I've been able to make some progress on the memory management chaneges. Still needs more work though. Feedback would be nice if anyone is testing.
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.
Quoted 5 lines
Things are working alright on my desktop with
base_timesliceat 10000 which corresponds to around 15-20 *second* timeslices, however I don't do much fancy, and it does have the problem of a newly forked CPU hog possibly causing a long freeze (fixable by using a smaller value for the first timeslice).
I think most people will find the long freeze worth avoiding, thanks for making it easily adjustable. As I found out when I was evaluating sorts and human interfaces that users would rather use a slower sort which didn't have a "jackpot case" than one which was 30% faster but linear in response. This was for 1-2sec typical response.
Just my guess.
Signature · 3 lines
-bill davidsen ([email protected]) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me