Re: [OT] 2.6 not 3.0 - (WAS Re: [PATCH-RFC] 4 of 4 - New problem logging macros, SCSI RAIDdevice)

From: Dave Jones (davej@codemonkey.org.uk)
Date: Thu Oct 03 2002 - 17:05:53 EST


On Thu, Oct 03, 2002 at 01:43:33PM -0700, Andrew Morton wrote:

> > > The memory management issues would qualify for 3.0, but my argument there
> > > is really that I doubt everybody really is happy yet. Which was why I
> > > asked for people to test it and complain about VM behaviour - and we've
> > > had some ccomplaints ("too swap-happy") although they haven't sounded like
> > > really horrible problems.
> >
> > We still need some work for low memory boxes (where low isn't
> > necessarily all that low). On my 128MB laptop I can lock up the box
> > for a minute or two at a time by doing two things at the same time,
> > like a bk pull, and switching desktops.
>
> Specific version info and all the usual how-to-reproduce info
> would help here. Things have changed a _lot_ in the past
> week or two.

That was 2.5.39 + bk from just before .40 hit the streets.
I'll pull something current in a tick, and give that a shot.

> Comparisons with 2.4 are useful. Simple "here's how to
> reproduce" instructions are 100% golden ;)

theres usually not too much going on on the laptop.
It runs enlightenment + gnome 1.4. A few gnome-terminals,
and thats about it. After bitkeeper had sucked down a few
changesets and started its "lets grind the disk for a while"
consistency thing, interactive feel is approaching nil.
Trying to focus a different window takes about 5 seconds minimum.
Switching desktops takes 30 seconds minimum.

My completely unscientific guess here is that bitkeeper is
whoring all the I/O bandwidth, and we're trying to swap at
the same time, which is getting starved.
I'll try and reproduce after some sleep with vmstat running
if this will be of use.

> > I dread to think how a 16 or 32MB box performs these days..
> Well last I looked, a 2.5 kernel with NR_CPUS=8 had 22MB
> of unreclaimable memory by the time it reached the console
> login prompt.

Ouch.

> Yet John Bradford says that in swapless 8MB, 2.5.40 is "springier"
> than 2.4.x, so weird.

Depends on what tests are I suppose. "springier" doesn't
really say too much. We do minimise memory usage in a few
places if mem<16M though iirc which could be helping this case.
 
> It should be immune to our traditional catastrophic failure
> scenarios, and that's something which we want to keep. There are
> some ten- or twenty-percent regressions in some areas, but at this
> time that's a reasonable price to pay for not locking up, not having
> five-minute comas, not exhibiting massive stalls when there's a
> lot of disk writeout, etc. I think history teaches us to value
> simplicity, predictability and robustness over performance-in-corner-cases.

Hmm, my case seems to be everything you say should not be happening
any more. Sorry 8-)
I *can't* be the only one seeing this though.
The laptop disk is no speed demon, but its quite nippy at ~12MB/s
For obvious reasons, having swap and / on the same disk is making
a considerable impact here.

                Dave

-- 
| Dave Jones.        http://www.codemonkey.org.uk
-
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/



This archive was generated by hypermail 2b29 : Mon Oct 07 2002 - 22:00:41 EST