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. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
