:On Mon, 25 Jan 1999 19:40:38 EST, Brian Feldman wrote: : :> I say this because I am down to ~2.5MB/s on each hard drive, a MB or :> so decrease; I also seem to be reading (bs=512k) from the CD uncooked :... : :Since I rebuilt world shortly after Matt's VM surgery started, I've also :noticed this -- lower apparent transfer rates from /dev/zero to disk, :higher CPU usage during such transfers. : :I'm _not_ saying it's Matt's stuff that's done this, it's just that that :was the stuff I _noticed_ happening in commit mail. I think I saw :something happening to wd.c recently as well, so I _definitely_ am not :going on record as laying blame. : :Just some confirmation. :-) : :Ciao, :Sheldon.
Hmm, interesting. A dd copy doesn't touch on the main of what I did, but I do have a (bad) hack in there to handle a case that John brought up in regards to the inactive page queue getting overloaded with clean meta-data. It might be interesting to turn that off and see if your transfer rates improve. You can turn off the hack by commenting out the case that activates it: Add the #if/#endif and split the open brace out from the else, as shown. I would like to know if your transfer rate improves or not, and by how much. /* * Figure out what to do with dirty pages when they are encountered. * Assume that 1/3 of the pages on the inactive list are clean. If * we think we can reach our target, disable laundering (do not * clean any dirty pages). If we miss the target we will loop back * up and do a laundering run. */ #if 0 if (cnt.v_inactive_count / 3 > page_shortage) { maxlaunder = 0; launder_loop = 0; } else #endif { maxlaunder = (cnt.v_inactive_target > max_page_launder) ? max_page_launder : cnt.v_inactive_target; launder_loop = 1; } -Matt Matthew Dillon <dil...@backplane.com> To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message