2.6.8-rc1-np1

2.6.8-rc1-np1

[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.

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.

Re: 2.6.8-rc1-np1

[Felipe Alfaro Solana]

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
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.

Re: 2.6.8-rc1-np1

[Nick Piggin]

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.

Re: 2.6.8-rc1-np1

[Martin Schlemmer]

[-- Attachment #1: Type: text/plain, Size: 2909 bytes --]

On Sat, 2004-07-17 at 11:25, Nick Piggin wrote:
> 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.
> 

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 ...

> > 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.

> 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/
-- 
Martin Schlemmer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: 2.6.8-rc1-np1

[Bill Davidsen]

Nick Piggin wrote:
> 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).

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.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me