Path: utzoo!attcan!uunet!samsung!zaphod.mps.ohio-state.edu!rpi!crdgw1!crdos1!davidsen From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr) Newsgroups: comp.arch Subject: Re: Fast /tmp Message-ID: <2361@crdos1.crd.ge.COM> Date: 24 Jul 90 14:37:50 GMT References: <10776@spool.cs.wisc.edu> <3734@auspex.auspex.com> Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen) Organization: GE Corp R&D Center, Schenectady NY Lines: 35 It's interesting to note that you get a similar effect when using a cached write-back disk controller. The kernel does the write neatly ordered and controller reorders on position for i/o. It's not obvious to sysadmins who install something like this that the performance gain comes with a (slight) increase in the chance of a blown f/s on power fail. Note that a software crash doesn't hurt the controller, so all data will be written anyway. The performance gains available by doing this are great, particularly on systems with light load, since the cpu is often not the bottleneck. Consider this system, used for mail and news: ________________________________________________________________ CPU in seconds cpu[IDLE] = 487647 ( 94.7%) wait[IO] = 8931 cpu[USER] = 8143 ( 1.6%) wait[SWAP] = 0 cpu[KERNEL] = 19299 ( 3.7%) wait[PIO] = 0 I/O counts bread = 286531 bwrite = 377804 lread = 8876796 lwrite = 3090676 readch = 1044977964 writech = 649909542 Process counts swapin = 0 swapout = 0 pswitch = 5154173 syscall = 29242599 sysfork = 68658 ________________________________________________________________ Although the lack of swap indicates enough memory, I would really want to have more before I dedicated any to ramdisk, but I suspect that just making /tmp a ramdisk of about 8MB would help performance a lot. -- bill davidsen (davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen) "Stupidity, like virtue, is its own reward" -me