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

From: Andreas Boman (aboman@nerdfest.org)
Date: Thu Oct 03 2002 - 22:46:34 EST


On Thu, 2002-10-03 at 17:05, Dave Jones wrote:
<SNIP>
> > > 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 ;)
Usually its difficult with theese 'feeling' issues though...

> 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.
>
<SNIP>
>
> > 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.
You arent ;)

> 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

I'm seeing similar behavior, though not to the extent you describe. 512M
ram, ~600 or so swap on a U160 scsi disk (only one disk in the box
-definitely need one more).

rpm -ba mozilla.spec and while its untar/gunziping i keep switching
desktops ("edge flip" in E) between one with a few Eterms and misc
stuff, and one with mozilla. At first it behaves fine, but eventually
the mouse pointer will start jerking around and itll be slightly slower
to switch, a little later the swapping starts and xmms will skip
(sometimes just once, othertimes repetedly). Once the untaring is done
and the build starts the box becomes responsive again.

Doing the same thing on 2.4.20-pre5aa2 xmms never skipped, starting a
build of mozilla and evolution at the same time, still no skipping. Drop
xmms and play a music video in MPLayer -still no skipping. I could even
move the MPlayer output window back and forth between the desktops
repetedly although i didnt move it around as fast as when i was just
switching desktops, without sound skips video playback did freeze up a
bit and left funky trails across the mozilla page at times), but sound
didnt skip. Sound started skipping when i had mozilla and evolution both
untar/ungzipping and I moved the window around madly between heads and
desktops.

the attached vmstat 1 from 2.5.40 is taken from when the build has just
started until a little after I killed it (when it had untared and
started ./configure). A little time goes by after i kill it I see a
little more IO and then the box just idles again.

-- 
Andreas Boman <aboman@nerdfest.org>



- 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:42 EST