Date: Mon, 7 Oct 2013 19:34:24 +0200 From: Davide Italiano <davide@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: Kirk McKusick <mckusick@freebsd.org>, alc@freebsd.org, freebsd-hackers <freebsd-hackers@freebsd.org>, freebsd-fs@freebsd.org, Ivan Voras <ivoras@freebsd.org>, pho@freebsd.org Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <CACYV=-GZPbC03stS6PsihfJ688kbjna2-n0%2BPdctr3L9hvSvag@mail.gmail.com> In-Reply-To: <201309031507.33098.jhb@freebsd.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
> What would perhaps be better than a hardcoded reclaim age would be to use > an LRU-type approach and perhaps set a target percent to reclaim. That is, > suppose you were to reclaim the oldest 10% of hashes on each lowmem call > (and make the '10%' the tunable value). Then you will always make some amount > of progress in a low memory situation (and if the situation remains dire you > will eventually empty the entire cache), but the effective maximum age will > be more dynamic. Right now if you haven't touched UFS in 5 seconds it > throws the entire thing out on the first lowmem event. The LRU-approach would > only throw the oldest 10% out on the first call, but eventually throw it all out > if the situation remains dire. > > -- > John Baldwin > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" I liked your idea more than what's available in HEAD right now and I implemented it. http://people.freebsd.org/~davide/review/ufs_direclaimage.diff I was unsure what kind of heuristic I should choose to select which (10% of) entries should be evicted so I just removed the first 10% ones from the head of the ufs_dirhash list (which should be the oldest). The code keeps rescanning the cache until 10% (or, the percentage set via SYSCTL) of the entry are freed, but probably we can discuss if this limit could be relaxed and just do a single scan over the list. Unfortunately I haven't a testcase to prove the effectiveness (or non-effectiveness) of the approach but I think either Ivan or Peter could be able to give it a spin, maybe. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACYV=-GZPbC03stS6PsihfJ688kbjna2-n0%2BPdctr3L9hvSvag>