home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / os / linux / 9828 < prev    next >
Encoding:
Internet Message Format  |  1992-09-03  |  2.0 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: Benchmarking under Linux (was Re: New 486 Suggestions?
  5. Message-ID: <1992Sep4.100706.12473@klaava.Helsinki.FI>
  6. Date: 4 Sep 92 10:07:06 GMT
  7. References: <1992Aug31.180211.24228@news.acns.nwu.edu> <1992Aug31.210041.21832@novell.com> <1992Sep2.175417.11302@pool.info.sunyit.edu>
  8. Organization: University of Helsinki
  9. Lines: 28
  10.  
  11. In article <1992Aug31.210041.21832@novell.com> bboerner@novell.com (Brendan B. Boerner) writes:
  12. >
  13. >This has me wondering: does anyone have any benchmarking or performance
  14. >metric programs for Linux?  I've got a 386/16Mhz w/a tad under 5MB of
  15. >RAM and it takes me somewhere between 3-4hours to build the kernel.  On
  16. >my girlfriend's machine, a 486/33 w/8MB RAM, it takes under 10
  17. >minutes.  I'd like to get an idea of where I could improve
  18. >performance.
  19.  
  20. RAM space is the first thing to look for: gcc eats memory like mad, and
  21. swapping is slow especially with the older kernels.  I hope my changes
  22. to the swap-algorithms in 0.97.pl3 will help people with slow machines:
  23. it does seem to help even on my 8MB machine (kernel compilation time
  24. when running X+some xterms fell from 18 minutes to 15).  The main change
  25. was to use a page-used counter instead of just a swp bitmap, which
  26. allows fork() to be speeded up /a lot/ when swapping. 
  27.  
  28. But processor speed can be very important under linux: not just for the
  29. obvious user-level speedup, but due to better response to disk-drive
  30. interrupts and the like.  Faster machines may simply read the disk at
  31. the full 1:1 interleave - with slower systems, it's possible that the HD
  32. driver doesn't keep up, and you get the dreaded 1-block/rotation
  33. syndrome, which really hurts when swapping.  This problem is probably
  34. especially notable on 386SX machines: the 386 interrupt handling is
  35. inherently slow, but if the memory badwidth is further reduced by the
  36. 16-bit bus, interrupt response is probably ever worse.
  37.  
  38.         Linus
  39.