Call fo comments - raising vfs.ufs.dirhash_reclaimage?

[Adrian Chadd]

Hi,

Please try it out on a -10 VM with something RAM limited - say, 128mb w/
GENERIC. See how it behaves.

I've successfully done buildworlds on 10-i386 with 128mb RAM. Let's try not
to break that before releng/10 is cut.

thanks,



-adrian



On 7 October 2013 23:34, Peter Holm <peter at holm.cc> wrote:

> On Mon, Oct 07, 2013 at 07:34:24PM +0200, Davide Italiano wrote:
> > > 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 at freebsd.org mailing list
> > > http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > > To unsubscribe, send any mail to "freebsd-fs-unsubscribe at 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.
> >
>
> I gave this patch a spin for 12 hours without finding any problems.
> I can do more testing at a later time, if you want to.
>
> - Peter
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>