Date: Tue, 8 Oct 2013 23:38:06 +0100 From: RW <rwmaillists@googlemail.com> To: freebsd-hackers@freebsd.org Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <20131008233806.54bb0483@gumby.homeunix.com> In-Reply-To: <CACYV=-HYCNeuP70JdFBrG9vXXj-E6E%2BOHcJ7Ov-Dzazx_59cag@mail.gmail.com> References: <kvkvi7$iv7$1@ger.gmane.org> <20130828181228.0d3618dd@ernst.home> <CAF-QHFU80YC3W-k%2BTKM=y3JiVYi=1fp5CJjbCCk1y0VKXzcRQg@mail.gmail.com> <201309031507.33098.jhb@freebsd.org> <CACYV=-GZPbC03stS6PsihfJ688kbjna2-n0%2BPdctr3L9hvSvag@mail.gmail.com> <20131008063433.GA47506@x2.osted.lan> <CAJ-VmonngDnZuphdsSP%2B4qGaz4u%2B%2B-bxzqrP5pqi80OOj64GSQ@mail.gmail.com> <CACYV=-HYCNeuP70JdFBrG9vXXj-E6E%2BOHcJ7Ov-Dzazx_59cag@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 8 Oct 2013 13:32:58 +0200 Davide Italiano wrote: > On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd <adrian@freebsd.org> > wrote: > > Hi, > > > > Hi Adrian, > > > Please try it out on a -10 VM with something RAM limited - say, > > 128mb w/ GENERIC. See how it behaves. Be aware that any test that doesn't cause vfs.ufs.dirhash_lowmemcount to increment isn't testing the change at all. > This is not supposed to hit 10-STABLE, at least not before proper > review. This is the reason why it was proposed on mailing lists. Also, > if you read the patch you'll end up with realizing this should behave > better on low memory environment because it unconditionally cleans 10% > of the cache every time. The current version deletes anything older than the time limit and if this doesn't reclaim 10% it makes a second pass through the list until the target is met. Your version tries to delete 10% (or whatever) by looping around the list until this is achieved. And if there aren't enough unlocked entries it will loop indefinitely until there are. I hope you know what you are doing because that looks very wrong. The original version looks better to me given that it already tries to free a minimum of 10%. The low-memory handler is called under very low memory conditions when the system is probably thrashing or even on the verge of killing processes. Holding on to entries that haven't been used for a minute seems like a luxury. > Previous changes in this area just did the > opposite keeping a lot more of memory around. I don't believe that's true. Under most circustances the existing scheme free more memory. The only case when yours frees more is when 90% of the entries are locked.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131008233806.54bb0483>