Date: Thu, 30 Oct 2003 18:59:56 -0800 (PST) From: Don Lewis <truckman@FreeBSD.org> To: kmarx@vicor.com Cc: mckusick@beastie.mckusick.com Subject: Re: 4.8 ffs_dirpref problem Message-ID: <200310310300.h9V2xueF033759@gw.catspoiler.org> In-Reply-To: <3FA1745A.2090205@vicor.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 30 Oct, Ken Marx wrote: > > > Don Lewis wrote: >> On 30 Oct, Ken Marx wrote: >>>Happy to test further if you have tweaks to your patch or >>>things you'd like us to test in particular. E.g., load, >>>newfs, etc. >> >> >> You might want to try your hash patch along my patch to see if >> decreasing the maximum hash chain lengths makes a difference in system >> time. >> >> > > Sorry - should hvae mentioned: Both tests included our hash patch. > I just re-ran with the hash stuff back to original. Sorry to say > there's no appreciable difference. Using your dirpref patch, still > apprx 75 sys sec/1.5gb: > > tot: 1185.54 real 14.15 user 747.43 sys > > Prehaps the dirpref patch lowers the frequency of having to search so much, > and hence exercises the hashtable less. I'm pretty sure that is the situation, but I wasn't sure if there was still enough hash table usage to make balancing it worthwhile. It sounds like there isn't. It looks like there is still about a 10% increase in system time for my modifications to dirpref versus reverting to the old algorithm. It would be nice to know where the extra time was being spent, but that would require probably require some kernel profiling. It might also be interesting to play with the cylinder group selection criteria. Should minbfree be 75% of avgbfree, 100% of avgbfree, or 125% of avgbfree? Probably not anything over 100%, since the algorithm would fail if all the cylinder groups were evenly filled ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310310300.h9V2xueF033759>