home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / linux / 8089 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  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: root disk vs. mj disk, also hd.c patch
  5. Message-ID: <1992Aug12.225636.5039@klaava.Helsinki.FI>
  6. Date: 12 Aug 92 22:56:36 GMT
  7. References: <1992Aug12.011334.17155@ultb.isc.rit.edu>
  8. Organization: University of Helsinki
  9. Lines: 37
  10.  
  11. In article <1992Aug12.011334.17155@ultb.isc.rit.edu> axi0349@ultb.isc.rit.edu (A.X. Ivasyuk ) writes:
  12. >
  13. >
  14. >First of all, how do you get the executables to be so tiny on the root disk
  15. >and the mj distribution?  I can't get mine under 9K, even a 'hello, world'
  16. >program.  I'd like to be able to squeeze my 80MB drive to the max.
  17. >It can't be just the -O flag on gcc.
  18.  
  19. By using shared libraries, and the "-N" flag, and stripping the result
  20. you can often make trivial binaries that are much less than 9kB. BUT
  21. they won't demand-load nor share pages, so it's worth it only if the
  22. binary is truly small. Using "-N" on bigger binaries will result in bad
  23. performance and memory waste when running it.
  24.  
  25. > [ Q two deleted ]
  26. >Third, where is the one-line patch to hd.c (0.97) that everyone has been talking
  27. >about?  I think I missed it on the net.  Could someone send it to me, please?
  28. >(I already applied patch1 and the buffer patch, and it did improve performance
  29. >noticeably, esp. patch1 - Thanks Linus!!!)
  30.  
  31. It's not to hd.c but to linux/fs/buffer.c - in the function
  32. grow_buffers(). 0.97.pl1 has code that looks something like this:
  33.  
  34.       for (i = 0 ; i+size <= 4096 ; i += size) {
  35.           bh = get_unused_buffer_head();
  36.           ....
  37. -         i += size;
  38.       }
  39.  
  40. As you can see, 'i' is updated twice ('i += size' both inside the
  41. for-loop and as the terminating expression), resulting in using only
  42. half the available space in a page for buffers.  The fix is to remove
  43. the line I have marked with a "-".  The above simple fix results in much
  44. better free memory utilization, and a marked improvement in performance
  45. under some circumstances. 
  46.  
  47.         Linus
  48.