--ngluH3DisTFy0Cjl
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Nov 13, 2005 at 01:38:13AM -0600, David Young wrote:
> On Sun, Nov 13, 2005 at 03:35:06PM +1100, Daniel Carosone wrote:
> > I'm guessing this problem is only really evident on machines without,
> > or with relatively small, swap space.  Otherwise, free pages in swap
> > would be 'available' to tmpfs, and when allocated would push out file
> > cache pages.
>=20
> I see the problem on a Soekris net4626 w/ 64MB RAM, no swap.

Sure.  So is the problem simply one of free space reporting?

I presume there's plenty of free RAM for your needs, and it's being
used for file cache for lack of something better to do with it. Let's
pretend you added swap, right at the moment you have this problem.
Nothing much changes about the memory usage of the system, but tmpfs
suddenly reports more free space.

Then you start using this space in /tmp. The pagedaemon wakes up, and
starts looking for work to do. Perhaps it will page out a few old data
pages from long-running, long-idle daemons, but most of what it will
do first is take pages from the file cache, since that's likely over
filemax allotment.

Some time later, the system has balanced out again, and is in
essentially the same state: all needed pages in memory, all pages not
used for anything better used for filecache, and the same small number
of truly "free" pages.  There are perhaps some other pages out in
swap, and mostly free ones in swap that tmpfs claims it can allocate
to files, but at the moment you want to actually grow a file in /tmp,
this is irrelevant for the free pages available right now without
sleeping and letting the pagedaemon run.

So the question is, do we really need the swap there if its going to
remain unused (at least until something grows considerably larger)?

What if tmpfs simply reported more free space, such as by not counting
the space used by (clean) filecache (above filemin? above filemax?) as
"used"?  Is tmpfs actually hitting a failure to allocate from uvm, or
just a synthetic filesystem free space counter?

--
Dan.
--ngluH3DisTFy0Cjl
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFDd62rEAVxvV4N66cRAnmeAKCeqkXdEpi8wf5r4JIvrt5q2+H58gCfcAnP
be3icMwW78Oll7srLi68GoM=
=/iGb
-----END PGP SIGNATURE-----

--ngluH3DisTFy0Cjl--