Xref: utzoo comp.unix.sysv386:2537 comp.unix.questions:27224 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!snorkelwacker.mit.edu!bloom-beacon!eru!hagbard!sunic!mcsun!hp4nl!philapd!apdnm!pb From: pb@idca.tds.PHILIPS.nl (P. Brouwer) Newsgroups: comp.unix.sysv386,comp.unix.questions Subject: Re: Tuning SYSVR3 (Esix Rev D) (LONG!) Message-ID: <1112@apdnm.idca.tds.philips.nl> Date: 29 Nov 90 08:29:47 GMT Sender: news@idca.tds.philips.nl Reply-To: pb@idca.tds.philips.nl (P. Brouwer) Lines: 24 Organisation: Philips Information Systems, Apeldoorn, The Netherlands. Disclamer: This opinion is mine alone. In article karl@ficc.ferranti.com (Karl Lehenbauer) writes: > >One annoying thing I've found about having 2 MB of cache is that the >system will periodically get incredibly sluggish for a few seconds. > >This happens right after big compiles and links. I assume it is because >"sync" is flushing all the dirty buffers. > The parameter BDFLUSHR specifies the time in seconds the interval between the check of the bdflush process ( part of the kernel ). If the interval is long , bdflush has probably more work to do. On the other hand bdflush has to check the complete cache for dirty buffers so if that has to be done in less activations per minute that will save some cpu time. You seem to suffer from the bdflush having to write a lot to disk. The default setting ( and max according to mtune ) for AT&T SYSV is 1. This constant is kept in a global kernel variable, which makes it possible to modify its value in a running kernel by writing the new value via kmem to the correct address. -- ________________________________________________________________________________ # Peter Brouwer, | Philips Information Systems, # # NET : pb@idca.tds.philips.nl | Department P9000-i Building V2, # # UUCP : ....!mcsun!philapd!pb | P.O.Box 245,7300AE Apeldoorn,The Netherlands#