--uZVCWN+Df+yHvs+i
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 14, 2005 at 09:43:23PM +0900, YAMAMOTO Takashi wrote:
> > > - not all filepages are reclaimable.
> >=20
> > 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.
>=20
> what's "%age"?

Sorry. The filemin (etc) values are stored as percentages (and as
per-256-ages), not as page counts.  The calculation to turn them into
page counts starts to look more and more like the kind already in uvm
code.

> > > - you seem to misuse uvmexp values in diff #2.
>=20
> usually, swpgavail =3D=3D swpages.

Oh, so it does! I looked too quickly at ddb "show uvmexp" it
seems. Thanks. I guess this is relevant when swap is being detached?

The right number is then swpgavail - swpginuse.

> > > - if you take this route, eventually you need to account buffer cache,
> > >   pool idle pages, etc.
> >=20
> > 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".
>=20
> please don't assume that other caches are negligible.
>=20
> your patch is simple because it only convers very simple cases.

Of course, and I'm only trying to. I'm not sure it's a problem,
either.  Again, I'm not trying to come up with an exact
free+reclaimable figure.  We all agree that's hard, and should be done
by uvm if at all.  If there was a uvmexp.exactlywhatwewant, sure, we'd
use it.

It's not necessary for tmpfs to display such an exact figure in df,
either. As a minimum requirement, I want a figure that's non-zero in
the case David found: no swap, memory full of filecache.

As long as that's non-zero, tmpfs can continue to grow if there's
demand.  I don't assume that other caches are negligible - but I rely
on the fact even if they are significant, that they will shrink in
response to the memory pressure from tmpfs allocations once it starts
growing and the pagedaemon runs.  At the moment, it won't create that
pressure, so the caches (quite rightly) use up all free memory.

To illustrate the point, using "size +=3D uvmexp.filepages / 2;" instead
would serve this purpose just as well.  It's totally arbitrary and
incorrect as a uvm value, but quite functional as a tmpfs growth
guard. Someone watching df will see more obviously surprising numbers,
moving in stranger ways, but those number (as you say) are special and
reflect all sorts of internal memory and system activity.

--
Dan.

(yes, ignore zero division and negative result in the above :)

--uZVCWN+Df+yHvs+i
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFDePs1EAVxvV4N66cRAl8KAKC8BDdztUbDwppW6WPlMAihLBaCHwCgisJ2
blnXsaGyioxm6VdW6IjrKQw=
=cIeP
-----END PGP SIGNATURE-----

--uZVCWN+Df+yHvs+i--