From: hedrick@dumas.rutgers.edu (Charles Hedrick) Subject: Re: response problem with 0.96c Date: 6 Jul 1992 01:54:36 GMT
dgraham@bmers30.bnr.ca (Douglas Graham) writes:
>Has anybody got any plans to look into the interrupt latency in Linux?
>I haven't noticed it being any worse in 0.96c, but it was none too great
>in previous releases anyway. It seems that the disk driver code
>keeps interrupts off for a bit longer that it ought to be doing. When
>I'm downloading, I can pretty well count on zmodem getting a CRC error
>every 30 seconds due to update calling sync(). Wouldn't it at least be
>possible most of the time, to leave the serial interrupt enabled while
>disabling other interrupts. That way, the serial ISR could go on stuffing
>characters into a buffer while the disk driver is doing it's thing.
As far as I know, Linux does not disable interrupts for specific
devices. It just uses cli and sti. I'd suggest that this is a
mistake. In most cases you only need to disable a specific device.
If I understand the hardware correctly, it's possible to do this by
masking that specific interrupt. Probably it's faster -- and causes
no trouble -- to do a cli/sti when you're trying to protect a sequence
or two or three instructions. But for anything longer, perhaps
something more specific could be done.
I agree about losing things at a sync. When I'm doing an FTP, the
transfer is interrupted whenever a buffer is written to the disk. My
complaint with 0.96c was more general -- I was getting drops more
often than that.