Hello.  Here is, perhaps, a sily suggestion.  What if you try breaking
into ddb when the machine seems particularly sluggish and running a back
trace?  I may not know what I'm talking about here, but perhaps in this way
you can catch the machine red-handed and somehow divine where the problem
is, or, at least, get closer?
I assume the behavior is easy to reproduce, so if you don't want to run
with a broken kernel all of the time, you can quicly do the test, and then
go back to your normal everyday system.
-Brian

On Jan 21,  5:02pm, "Steven M. Bellovin" wrote:
} Subject: Re: jerky interactive behavior
} On Sun, 21 Jan 2007 16:48:15 -0500
} "Perry E. Metzger" <perry@piermont.com> wrote:
} 
} > 
} > "Steven M. Bellovin" <smb@cs.columbia.edu> writes:
} > >> As of Jan, something seems to have broken BUFQ_READPRIO -- unclear
} > >> who did it or why, but it is very clear to me that it got broken.
} > >> The old symptoms of lots of disk i/o locking out userland
} > >> processes trying to read something have returned.
} > >> 
} > > I do indeed have BUFQ_READPRIO defined, but I'm far from convinced
} > > that that's the problem -- this is happening without any
} > > disk-intensive activity going on in the background.  Sure, there's
} > > always something some daemon is doing, but I've tried shutting down
} > > other things.
} > 
} > I've been looking very carefully at my disk light when the hangs
} > happen, and there is usually disk i/o in progress when the hangs
} > occur. Are you sure your disk light on your T41 isn't going off at the
} > same time at all?
} > 
} Certain?  No.  But I've been watching it, too. 
} 
} 
} 
} 		--Steve Bellovin, http://www.cs.columbia.edu/~smb
>-- End of excerpt from "Steven M. Bellovin"


ייייי.