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