[lkml]   [2002]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [BUG] 2.4 VM sucks. Again
On Fri, May 31, 2002 at 06:56:54PM +0200, Roy Sigurd Karlsbakk wrote:
> > I suspect nuke-buffers is simply always the right thing to do. It's
> > what 2.5 is doing now (effectively). We'll see...
> >
> > But in your case, you only have a couple of gigs of memory, iirc.
> > You shouldn't be running into catastrophic buffer_head congestion.
> > Something odd is happening.
> >
> > If you can provide a really detailed set of steps which can be
> > used by others to reproduce this, that would really help.
> What I do: start lots (10-50) downloads, each with a speed of 4,5Mbps from
> another client. The two are connected using gigEthernet. downloads are over
> HTTP, with Tux or other servers (have tried several). If the clients are
> reading at full speed (e.g. only a few clients, or reading directly from
> localhost), the problem doesn't occir. However, when reading at a fixed rate,
> it seems like the server is caching itself to death.
> Detailed configuration:
> - 4 IBM 40gig disks in RAID-0. chunk size 1MB
> - 1 x athlon 1GHz
> - 1GB RAM - no highmem (900 meg)
> - kernel 2.4.19pre7 + patch from Andrew Morton to ditch buffers early
> (thread: [BUG] 2.4 VM sucks. Again)
> - gigEthernet between test client and server
> Anyone got a clue?

can you try to reproduce with 2.4.19pre9aa2 just in case it's an oom
deadlock, and if it deadlocks again can you press SYSRQ+T, and many
times SYSQR+P, and send this info along the (you may need the
serial console to easily gather the data if not even a SYSRQ+I is able
to let the box resurrect from the livelock). (the possibly
not on l-k because it's quite big)


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:26    [W:0.069 / U:0.972 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site