home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9347 < prev    next >
Encoding:
Text File  |  1992-08-29  |  4.5 KB  |  104 lines
  1. Newsgroups: comp.os.linux
  2. Path: sparky!uunet!snorkelwacker.mit.edu!bloom-picayune.mit.edu!daemon
  3. From: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  4. Subject: Re: 0.97p2
  5. Message-ID: <1992Aug29.175510.25324@athena.mit.edu>
  6. Sender: daemon@athena.mit.edu (Mr Background)
  7. Reply-To: tytso@ATHENA.MIT.EDU (Theodore Ts'o)
  8. Organization: The Internet
  9. Date: Sat, 29 Aug 1992 17:55:10 GMT
  10. Lines: 92
  11.  
  12.    From: torvalds@klaava.Helsinki.FI (Linus Benedict Torvalds)
  13.    Date: 28 Aug 92 23:05:26 GMT
  14.  
  15.    Hmm.  I'd like to hear more about the problem - especially if you can
  16.    pinpoint it more closely (ie having used 0.97, 0.97.pl1 and now pl2) to
  17.    a specific patch.  As most people said 0.97.pl1 was fast, I'm assuming
  18.    it's specific to patch2, but I'd like to have some confirmation before I
  19.    start looking into the problem. 
  20.  
  21. Whether or not a particular version is fast is probably dependent on how
  22. much memory you have.  I ran a controlled series of tests by running
  23. 0.96c, 0.97, 0.97pl1, and 0.97pl2 on my 40 MhZ 386 machine (with 16meg
  24. memory), I noticed no appreciable difference in times:
  25.  
  26. Ver.    Time to compile the stock 0.97 
  27.     kernel after doing a "make clean"
  28.  
  29. 0.96c     9:35    (*)
  30.      9:33
  31.      9:34
  32.  
  33. 0.97    10:21    (*)
  34.      9:41
  35.  
  36. 0.97pl1    10:10    (*)
  37.      9:45
  38.      9:32
  39.  
  40. 0.97pl2    10:36    (*)
  41.      9:25
  42.      9:30
  43.     10:11    (*)
  44.      9:41
  45.  
  46. All of these times were measured by doing (date;make;date) >& MAKELOG
  47. and then measuring the difference between the first and second time.
  48. The only processes that were running on the machine other than the
  49. compile was the X server and a single xterm.  The (*) times indicate the
  50. first compile after a reboot; the (*) times are higher because the
  51. buffer cache hasn't been primed yet.
  52.  
  53. So at least if you have a lot of memory, there is no appreciable
  54. difference between 0.96c, 0.97, 0.97p1, and 0.97p2.  If I had to make a
  55. guess, I would guess that the problem happens on machines with less
  56. memory --- say, 4 or 8 megabytes, and I further guess that it might be
  57. related to the buffer changes.  It could very well be that the poeple
  58. who said that 0.97pl1 was fast were running with a lot of memory.
  59.  
  60.    If it's patch2, the problem is probably the changed mm code: having
  61.    different page tables for each process might be costlier than I thought. 
  62.    The old (pre-0.97.pl2) mm was very simple and efficient - TLB flushes
  63.    happened reasonably seldom.  With the new mm, the TLB gets flushed at
  64.    every task-switch (not due to any explicit flushing code, but just
  65.    because that's how the 386 does things when tasks have different
  66.    cr3's). 
  67.  
  68. I don't think the TLB cache flush would be much of a problem.  Consider:
  69. There are 32 entries in the TLB, and if you reference a page which is
  70. not in the TLB, you pay a penalty of between 0 and 5 cycles.  So the
  71. maximum penalty you incur by flushing the TLB is 5x32 or 160 cycles.  If
  72. you further assume the worst case that you are switching contexts every
  73. tick of the 100hz clock, then you will flushing the TLB 100 times a
  74. second, or taking a penalty of 16,000 cycles/second.  On a 16MHz machine,
  75. there are 16 x 10**6 cycles/second.  So the worst case extra time
  76. incurred by flushing the TLB is (16 x 10**3) / (16 x 10**6) == 10**-3,
  77. or an overhead of 0.1%.  On a 40MHz machine, this overhead declines to
  78. 0.04%.
  79.  
  80. Now, these times do assume that the page table/directories haven't
  81. gotten paged out to disk.  Since each process must now have at least one
  82. page directory and two page tables (one for low memory and one for the
  83. stack segment in high memory), if you assume a 2 meg system has 8-9
  84. processes running, 24 4k pages, or 10% of its user memory is being used
  85. to hold the page tables/directories.  This has two effects; the first is
  86. to increase the memory usage, which may increase thrashing.  The second
  87. is that if these pages get swapped out, the kernel will have to bring
  88. them in again the moment that process starts executing again, since the
  89. TLB cache will be empty.
  90.  
  91.    I can optimize things a bit - it's reasonably easy to fake away some of
  92.    the TLB flushes by simply forcing the idle task to always use the same
  93.    cr3 as the last task did (as the idle task runs only in kernel memory,
  94.    and kernel memory is the same for all processes).  So, I'd be interested
  95.    to hear if this simple patch speeds linux up at all:
  96.  
  97. Given my back of the envelope calculations above, I would be doubtful if
  98. this patch speeds up Linux by any appreciable amount.  And any speed
  99. improvement will probably be taken up by the extra time to do the 
  100. extra check in the scheduler.  But this is only a theoretical guess;
  101. someone should probably gather experimental evidence to make sure.
  102.  
  103.                             - Ted
  104.