Subject: Re: free space (was /dev) on tmpfs problem
To: YAMAMOTO Takashi <>
From: Daniel Carosone <>
List: tech-kern
Date: 11/14/2005 23:27:19
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Mon, Nov 14, 2005 at 07:15:46PM +0900, YAMAMOTO Takashi wrote:
> - not all filepages are reclaimable.

Yah, I'd also like to back off by filemin worth of pages, without
duplicating the code that turns the %age to a page count. Suggestions
welcome for better metrics and fine tuning.

> - uvmexp.inactive is not appropriate as it includes anonymous pages.

I noticed this just after posting, doh. :)

> - this kind of calculation should be done in uvm, not tmpfs.

Sure, especially if we want an exact count that's the same count as
some other part of the system wants for other purposes.

> - you seem to misuse uvmexp values in diff #2.

How so? It seems to give the same results and behaviour as the
previous code (ignoring the filepages contribution) when I add and
remove swap, and cause swapping.  I don't think interrupt races
between taking each value are likely to be important either.

> - if you take this route, eventually you need to account buffer cache,
>   pool idle pages, etc.

Nah. I'm not trying to find every last free page - if you're
scrounging for scraps like this, you need to add swap or reduce usage.
I just want to find a better approximation that recognises cache pages
as "fair game".

As you point out for the -s case, even if the estimate is high it just
means tmpfs users may sleep a long time for allocation as things fill
up.  It would be better as a low estimate, though not as low an
estimate as now which ignores all filecache.

Content-Type: application/pgp-signature
Content-Disposition: inline

Version: GnuPG v1.4.2 (NetBSD)