On Tue, Oct 8, 2013 at 3:38 PM, RW <rwmailli...@googlemail.com> wrote: > On Tue, 8 Oct 2013 13:32:58 +0200 > Davide Italiano wrote: > >> On Tue, Oct 8, 2013 at 1:25 PM, Adrian Chadd <adr...@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. >
Hi (RW..?), This could be probably changed -- from what | see even under high memory pressure this wasn't a problem but all in all I agree with you that we shouldn't loop forever but limit the number of pass on the list to a somewhat constant number, to prevent pathological cases. > 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. Well, no. Here you can set the threshold to a more aggressive value so that you reclaim more memory every time. Note that this was not possible in the previous version, so, if you could have a situation where all your cache entries were not touched for 15 or even 30 seconds they would have kept around, and you can destroy up to 10% of them everytime lowmem event is called. Thanks, -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"