Path: utzoo!attcan!uunet!lll-winken!sun-barr!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!ncar!boulder!pogo.Colorado.EDU!giltner From: giltner@boulder.Colorado.EDU (Jon Giltner) Newsgroups: comp.unix.ultrix Subject: Performance Tuning Ultrix 4.0 Keywords: Ultrix 4.0, Performance Message-ID: Date: 22 Oct 90 21:16:51 GMT Sender: news@boulder.Colorado.EDU Reply-To: giltner@pogo.Colorado.EDU Distribution: na Lines: 31 This in in regard to the article posted several weeks ago by Corey Satten and Laurence Lundblade at the University of Washington about Tuning Ultrix 4.0 to encourage paging (over swapping). Everything they described makes sense to me EXCEPT why Ultrix 4.0 seemed so much slower than Ultrix 3.1 in the first place (the lotsfree, desfree, and minfree values did not change). What HAS changed is they way swap space is allocated. Ultrix 4.0 has abandoned the familiar (4BSD) scheme of dmmin and dmmax (where dmmin space is allocated sequentially, then if more is needed dmmin*2 space is allocated sequentially and so on up to allocating dmmax chunks sequentially). Instead Ultrix 4.0 has a configuration option called swapfrag. Swap space is allocated swapfrag 512-byte blocks at a time. By default this number is 64, which is 2*(default dmmin) under Ultrix 3.1. Under the dmmin, dmmax scheme allocating about 1MB of swap space took 6 or 7 requests and the result was a few large chunks. Under the new scheme, it appears that a 1MB allocation requires about 30 requests resulting in 30 32k chunks spread throughout the swap area. This could result in the "thrashing" that some of us have experienced under 4.0. It seems that we are now forced to strike a balance between swap space wastage (if swapfrag is large and some processes are small) and performance. Is there something that I am missing? I'd like to know the motivation behind this change. Jon Giltner University of Colorado Computing and Network Services giltner@pogo.Colorado.EDU :wq