home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / os / linux / 6393 < prev    next >
Encoding:
Internet Message Format  |  1992-07-22  |  2.9 KB
  1. Path: sparky!uunet!mcsun!news.funet.fi!hydra!klaava!torvalds
  2. From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  3. Newsgroups: comp.os.linux
  4. Subject: Re: Better serial throughput: another approach
  5. Message-ID: <1992Jul21.201858.11059@klaava.Helsinki.FI>
  6. Date: 21 Jul 92 20:18:58 GMT
  7. References: <Jul.19.16.41.19.1992.22509@dumas.rutgers.edu> <2A6C23D4.5D7F@tct.com>
  8. Organization: University of Helsinki
  9. Lines: 56
  10.  
  11. In article <2A6C23D4.5D7F@tct.com> chip@tct.com (Chip Salzenberg) writes:
  12. >According to hedrick@dumas.rutgers.edu (Charles Hedrick):
  13. >>I've finally concluded that there's just too much code being
  14. >>executed per character.
  15. >
  16. >There is another way, as SCO does:
  17. >
  18. >   At serial interrupt: just store the character in a queue and return.
  19. >     Don't go through scheduler, just return.
  20. >
  21. >   At clock interrupt: pull characters off the queues and do the rest
  22. >     of the processing that is currently happening at serial interrupt
  23. >     time.  Then run the scheduler, _once_.
  24. >
  25. >Presto: minimum-overhead serial I/O.
  26.  
  27. This is in fact how linux does it already: the problem has been to find
  28. the offending code.  As I haven't actually seen the character loss, I
  29. originally thought it was either bad interrupt latency or simply too
  30. slow serial interrupt routines.  After more testing (mainly thanks to
  31. hedrick), it seems the problem is actually the clock interrupt routine:
  32. it's too slow. 
  33.  
  34. "Why would the system care how slow the clock interrupt is?" - the
  35. reason is simple: interrupts are enabled while the serial interrupt
  36. happens, so the following can happen:
  37.  
  38.     serial interrupt received: handler started
  39.         timer interrupt received: immediate response
  40.         timer interrupt does the serial copying, returns
  41.     serial handler returns.
  42.     
  43. The result is that while the serial code is fast enough, it can get
  44. interrupted by the timer interrupt (which happens 100 times a second:
  45. not too surprising if it happens while the serial handler is active
  46. every now and then).
  47.  
  48. The timer interrupt isn't that complicated, but it does do the
  49. copy_to_cooked routine, which can take some time.  So, there are four
  50. possibilities: (a) make the serial interrupt handler atomic or (b) speed
  51. up the copy_to_cooked routine or (c) move copy_to_cooked from within the
  52. timer-interrupt to some less time-critical place and (d) rewrite the
  53. general tty handlers totally to have less need for the copy-to-cooked
  54. routines. 
  55.  
  56. I'm in fact looking into all four possibilities, and 0.97 will contain
  57. one or several of the fixes.  One way of getting slightly better
  58. performance already is to use the patch by hedrick, which essentially
  59. speeds up copy_to_cooked by making some of the help-function inline etc. 
  60.  
  61. [ Note that you cannot right now use SA_INTERRUPT to install a serial
  62. handler that is totally atomic: it's still interruptible in the general
  63. IRQ handling code.  I'll have to change this for the next version
  64. anyway, as the old problems with some (buggy?) harddisks are back ]
  65.  
  66.         Linus
  67.