Linux 2.4.17 vs 2.2.19 vs rml new VM

Linux 2.4.17 vs 2.2.19 vs rml new VM

[brian]

I'd like to say that as of 2.4.17 w/preempt patch, the linux kernel
seems again to perform as well as 2.2.19 for interactive use and
reliability, at least in my use.

2.4.17 still croaks running some of the giant memory applications
that I run successfully on 2.2.19. (Machines with 2GB of RAM 
running 3GB+ apps.)

I tried rmap-10 new VM and under my typical load my desktop machine
froze repeatedly.  Seemed the memory pool was going down the drain
before the freeze. Meaning apps were failing and getting stuck in
various odd states.

No doubt, preempt and rmap-10 are incompatible, but I'm not going to
give up the preempt patch any time soon.

All in all 2.4.17 w/preempt is very satisfactory.

-- 
Brian Litzinger <brian@worldcontrol.com>

    Copyright (c) 2002 By Brian Litzinger, All Rights Reserved

Re: Linux 2.4.17 vs 2.2.19 vs rml new VM

[Alan Cox]

> I tried rmap-10 new VM and under my typical load my desktop machine
> froze repeatedly.  Seemed the memory pool was going down the drain
> before the freeze. Meaning apps were failing and getting stuck in
> various odd states.
> 
> No doubt, preempt and rmap-10 are incompatible, but I'm not going to
> give up the preempt patch any time soon.

I suspect its rmap-10 not the pre-empt patch. If you have the
time/inclination then testing just that load with rmap10a (the fixed rmap10)
would be interesting just to know which bit is the buggy half.

Similarly the low latency patch which on the whole seems to give better
results than the preempt patches is much less likely to cause problems as it
doesn't really change the system semantics in the same kind of way

Re: Linux 2.4.17 vs 2.2.19 vs rml new VM

[Rik van Riel]

On Wed, 2 Jan 2002 brian@worldcontrol.com wrote:

> I tried rmap-10 new VM and under my typical load my desktop machine
> froze repeatedly.  Seemed the memory pool was going down the drain
> before the freeze. Meaning apps were failing and getting stuck in
> various odd states.

There's a stupid logic inversion bug in rmap-10, which is
fixed in rmap-10a. Andrew Morton tracked it down about an
hour after I released rmap-10.

Basically in wakeup_kswapd() user processes go to sleep
if the pressure on the VM is _really_ high *and* the user
process has all the same GFP options set as kswapd itself,
so the process can sleep on kswapd.

	if ((gfp_mask & GFP_KSWAPD) == GFP_KSWAPD)
		return;

Thinking about it, rmap-10a doesn't do the right thing,
either, releasing patches at 4 am isn't the right thing ;)

In vmscan.c, line 707 _should_ be:

	if ((gfp_mask & GFP_KSWAPD) != GFP_KSWAPD)
		return;

This way tasks which cannot safely sleep on kswapd will
return immediately, allowing only tasks which _can_
sleep on kswapd to go for a break.

Oh well, time for testing and releasing rmap-11 ;)

regards,

Rik
-- 
Shortwave goes a long way:  irc.starchat.net  #swl

http://www.surriel.com/		http://distro.conectiva.com/

Re: Linux 2.4.17 vs 2.2.19 vs rml new VM

[J Sloan]

Just .02 from the peanut gallery -

It would be interesting if you were to compare and
contrast 2.4.17-preempt with 2.4.17-low-latency.

I find the low latency patch makes a noticeable
difference in e.g. q3a and rtcw - OTOH I have
not been able to discern any tangible difference
from the stock kernel when using -preempt.

cu

jjs

brian@worldcontrol.com wrote:

>I'd like to say that as of 2.4.17 w/preempt patch, the linux kernel
>seems again to perform as well as 2.2.19 for interactive use and
>reliability, at least in my use.
>
>2.4.17 still croaks running some of the giant memory applications
>that I run successfully on 2.2.19. (Machines with 2GB of RAM 
>running 3GB+ apps.)
>
>I tried rmap-10 new VM and under my typical load my desktop machine
>froze repeatedly.  Seemed the memory pool was going down the drain
>before the freeze. Meaning apps were failing and getting stuck in
>various odd states.
>
>No doubt, preempt and rmap-10 are incompatible, but I'm not going to
>give up the preempt patch any time soon.
>
>All in all 2.4.17 w/preempt is very satisfactory.
>

Re: Linux 2.4.17 vs 2.2.19 vs rml new VM

[Alan Cox]

> I find the low latency patch makes a noticeable
> difference in e.g. q3a and rtcw - OTOH I have
> not been able to discern any tangible difference
> from the stock kernel when using -preempt.

The measurements I've seen put lowlatency ahead of pre-empt in quality
of results. Since low latency fixes some of the locked latencies it might
be interesting for someone with time to benchmark

	vanilla
	low latency
	pre-empt
	both together

Re: Linux 2.4.17 vs 2.2.19 vs rml new VM

[Dieter Nützel]

On Tuesday, 2. January 2002 20:50, Alan cox wrote:
> > I find the low latency patch makes a noticeable
> > difference in e.g. q3a and rtcw - OTOH I have
> > not been able to discern any tangible difference
> > from the stock kernel when using -preempt.
>
> The measurements I've seen put lowlatency ahead of pre-empt in quality
> of results. Since low latency fixes some of the locked latencies it might
> be interesting for someone with time to benchmark
>
>        vanilla
>        low latency
>        pre-empt
>        both together

Don't forget that you have to use preempt-kernel-rml + lock-break-rml to 
achieve the same (more) than the latency patch.

Taken from Robert's page and running it for some weeks, now.

[-]
Lock breaking for the Preemptible Kernel
lock-break-rml-2.4.15-1
lock-break-rml-2.4.16-3
lock-break-rml-2.4.17-2
lock-break-rml-2.4.18-pre1-1
README
ChangeLog
With the preemptible kernel, the need for explicit scheduling points, like in 
the low-latency patches, are no more. However, since we can not preempt while 
locks are held, we can take a similar model as low-latency and "break" (drop 
and immediately reacquire) locks to improve system response. The trick is 
finding when and where we can safely break the locks (periods of quiescence) 
and how to safely recover. The majority of the lock breaking is in the VM and 
VFS code. This patch is for users with strong system response requirements 
affected by the worst-case latencies caused by long-held locks.
[-]

Regards,
	Dieter

-- 
Dieter Nützel
Graduate Student, Computer Science

University of Hamburg
@home: Dieter.Nuetzel@hamburg.de

Re: Linux 2.4.17 vs 2.2.19 vs rml new VM

[J Sloan]

Well it is possible that with the several patches
you mention that I might see results similar to
what I now see with the low-latency patch.

However -

The preempt patch does NOT play well with the
tux webserver, which I am using. So, preempt is
not an option for me until and unless it is cleaned
up to allow cooperation with tux.

tux and low-latency get along just fine.

cu

jjs

Dieter Nützel wrote:

>On Tuesday, 2. January 2002 20:50, Alan cox wrote:
>
>>>I find the low latency patch makes a noticeable
>>>difference in e.g. q3a and rtcw - OTOH I have
>>>not been able to discern any tangible difference
>>>from the stock kernel when using -preempt.
>>>
>>The measurements I've seen put lowlatency ahead of pre-empt in quality
>>of results. Since low latency fixes some of the locked latencies it might
>>be interesting for someone with time to benchmark
>>
>>       vanilla
>>       low latency
>>       pre-empt
>>       both together
>>
>
>Don't forget that you have to use preempt-kernel-rml + lock-break-rml to 
>achieve the same (more) than the latency patch.
>
>Taken from Robert's page and running it for some weeks, now.
>
>[-]
>Lock breaking for the Preemptible Kernel
>lock-break-rml-2.4.15-1
>lock-break-rml-2.4.16-3
>lock-break-rml-2.4.17-2
>lock-break-rml-2.4.18-pre1-1
>README
>ChangeLog
>With the preemptible kernel, the need for explicit scheduling points, like in 
>the low-latency patches, are no more. However, since we can not preempt while 
>locks are held, we can take a similar model as low-latency and "break" (drop 
>and immediately reacquire) locks to improve system response. The trick is 
>finding when and where we can safely break the locks (periods of quiescence) 
>and how to safely recover. The majority of the lock breaking is in the VM and 
>VFS code. This patch is for users with strong system response requirements 
>affected by the worst-case latencies caused by long-held locks.
>[-]
>
>Regards,
>	Dieter
>