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