System unresponsive during HDD activity
Konstantin Svist
fry.kun at gmail.com
Fri Sep 17 20:01:08 UTC 2010
On 09/17/2010 11:36 AM, Robert Myers wrote:
> I've never thought that there was anything more complicated to this
> phenomenon than that keyboard and disk i/o are both serviced by
> interrupts.
It's true that both are serviced by interrupts, but they're separate
hardware interrupts -- and the very essence of interrupt programming
requires that all interrupts must be processed very quickly (limited
number of CPU cycles - set a flag and exit the interrupt) - so it's not
the interrupts themselves that are the problem.
> Not only that, but I think the problem is fundamental. You have two
> real-time processes competing for processor time and constantly
> attempting to interrupt one another.
Whoa, whoever said "svn up" or "get all mail" should be a real-time
priority process?!
And pressing a button/sending the keystroke through an established ssh
session/etc. should not take all that many cycles, anyway!
> Even if you try to set priorities so that keystrokes get first call on
> the processor's attention, the system has to do a lot of save and
> restore to respond to each one of those keystrokes, and, unless you
> don't care about data corruption, some disk tasks, once initiated,
> absolutely must be attended to.
I disagree - that's what DMA is for. The CPU allocates memory and stores
the to-be-written-to-disk data there, then hands it off to the disk
controller.
After that, the controller must interrupt the CPU only if something
happens (problem or finished writing). The CPU should never have to sit
and wait for the disk to finish its thing.
> If you push things hard enough, you wind up with a situation that is
> somewhat analogous to a traffic jam on a freeway: the throughput of
> the entire system drops precipitously because all of the margins for
> error have been exhausted, and you wind up with mutually-interrupting
> processes queued up and traffic nearly at a stand-still.
I agree - but this was nothing of the sort. It's a single task that
didn't take up all the CPU cycles - just a lot of disk I/O. It should
have minimal effect on non-disk operations.
More information about the users
mailing list