Call fo comments - raising vfs.ufs.dirhash_reclaimage?

[John Baldwin]

On Wednesday, August 28, 2013 12:40:15 pm Ivan Voras wrote:
> On 28 August 2013 18:12, Gary Jennejohn <gljennjohn at googlemail.com> wrote:
> 
> > So, if I understand this correctly, a normal desktop user won't
> > notice any real change, except that buildworld might get faster,
> > and big servers will benefit?
> 
> Basically, yes, but read on...
> 
> > But could this negatively impact small, embedded systems, which
> > usually have only small memory footprints?  Although I suppose
> > one could argue that they usually don't have large numbers of
> > files cached in memory at any given time.
> 
> Unless I'm wrong, the only pathological case coming from this change
> would be the following sequence of events:
> 
> 1) Memory is scarce [*]
> 2) There's a sudden surge of requests for a huge number of different directories
> 3) There's an urgent lowmem event which is observed by dirhash, which
> attempts to free memory but is prevented in doing so for the next 60
> seconds because all entries are young (the idea behind dirhash being
> that if a directory is accessed, it will probably soon be accessed
> again - think "ls" then "fopen", so we won't evict him until
> reclaimage seconds)
> 4) the kernel runs out of memory, game over.

Just to play devil's advocate, the only way your change can benefit is
if:

1) Memory is scarce thus triggering a lowmem event
2) There are requests for a huge number of directories that haven't been
   accessed in over 5 seconds.

That is to say, what your change does is increase the relative importance
of dirhash memory relative to other memory in the machine when the machine
is under memory pressure.  If the machine is not under memory pressure then
the lowmem handler will not be triggered and your change will never matter.

Keep in mind that if pagedaemon is able to keep up, the lowmem event handler
will not be called.  This handler only triggers when you are really low on
memory and trying to allocate it faster than pagedaemon can reclaim free
pages.  In that sort of environment you generally want caches to return
pages sooner rather than later.

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