Date: Tue, 3 Sep 2013 15:07:32 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-fs@freebsd.org Cc: freebsd-hackers <freebsd-hackers@freebsd.org>, Ivan Voras <ivoras@freebsd.org> Subject: Re: Call fo comments - raising vfs.ufs.dirhash_reclaimage? Message-ID: <201309031507.33098.jhb@freebsd.org> In-Reply-To: <CAF-QHFU80YC3W-k%2BTKM=y3JiVYi=1fp5CJjbCCk1y0VKXzcRQg@mail.gmail.com> References: <kvkvi7$iv7$1@ger.gmane.org> <20130828181228.0d3618dd@ernst.home> <CAF-QHFU80YC3W-k%2BTKM=y3JiVYi=1fp5CJjbCCk1y0VKXzcRQg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday, August 28, 2013 12:40:15 pm Ivan Voras wrote: > On 28 August 2013 18:12, Gary Jennejohn <gljennjohn@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201309031507.33098.jhb>