home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9305 < prev    next >
Encoding:
Internet Message Format  |  1992-08-29  |  2.4 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: 0.97p2
  5. Message-ID: <1992Aug28.230526.7253@klaava.Helsinki.FI>
  6. Date: 28 Aug 92 23:05:26 GMT
  7. References: <1992Aug28.123817.20350@csd.uch.gr>
  8. Organization: University of Helsinki
  9. Lines: 50
  10.  
  11. In article <1992Aug28.123817.20350@csd.uch.gr> kermits@pasifae.cc.uch.gr (Aggelos Keromyths) writes:
  12. >I just tried 0.97p2 from the disk drive and it seemed to me a lot
  13. > slower than 0.97 (no patch at all!!!)....When i did an `ls` it
  14. > started reading the drive,then stopped,then again reading and finally
  15. > presented the directory...but it was SLOW....
  16. >What could be the problem ?
  17.  
  18. Hmm.  I'd like to hear more about the problem - especially if you can
  19. pinpoint it more closely (ie having used 0.97, 0.97.pl1 and now pl2) to
  20. a specific patch.  As most people said 0.97.pl1 was fast, I'm assuming
  21. it's specific to patch2, but I'd like to have some confirmation before I
  22. start looking into the problem. 
  23.  
  24. If it's patch2, the problem is probably the changed mm code: having
  25. different page tables for each process might be costlier than I thought. 
  26. The old (pre-0.97.pl2) mm was very simple and efficient - TLB flushes
  27. happened reasonably seldom.  With the new mm, the TLB gets flushed at
  28. every task-switch (not due to any explicit flushing code, but just
  29. because that's how the 386 does things when tasks have different cr3's). 
  30.  
  31. I can optimize things a bit - it's reasonably easy to fake away some of
  32. the TLB flushes by simply forcing the idle task to always use the same
  33. cr3 as the last task did (as the idle task runs only in kernel memory,
  34. and kernel memory is the same for all processes).  So, I'd be interested
  35. to hear if this simple patch speeds linux up at all:
  36.  
  37.  - in linux/kernel/sched.c: schedule() - change
  38.  
  39.     cli();
  40.     switch_to(next);
  41.  
  42.    to
  43.  
  44.     cli();
  45. +     if (!next)
  46. +         task[0]->tss.cr3 = current->tss.cr3
  47.     switch_to(next);
  48.  
  49.    ie just add the one if-statement.
  50.  
  51. If the above makes a difference, I'd like to hear it, and I'll put it in
  52. the standard kernel.
  53.  
  54. I'd also like to know what kind of machines the slowdown is most
  55. noticeable on: assuming it's the mm changes I'd guess it's non-cached
  56. machines (possibly SX-machines) for which a TLB flush will result in a
  57. noticeable performance-loss.  So if you notice a slowdown, please mail
  58. me that kind of info as well. 
  59.  
  60.         Linus
  61.