Subject: Re: jerky interactive behavior
To: Steven M. Bellovin <firstname.lastname@example.org>
From: Brian Buhrow <email@example.com>
Date: 01/21/2007 15:31:59
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.
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" <firstname.lastname@example.org> wrote:
} > "Steven M. Bellovin" <email@example.com> 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"