On 11/13/05, Daniel Carosone <dan@geek.com.au> wrote:
> 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.
> >
> > 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?

I'm not sure it's just a problem in the space counter.  However, it should =
be
easy enough to test; there is a macro in tmpfs.h that returns this number,
so you'd try to tweak it.  Sorry, I have no time nowadays to test and try t=
o
fix this issue...  (which unfortunately is very important to get fixed to h=
ave
a usable tmpfs on swapless machines).

--
Julio M. Merino Vidal <jmmv84@gmail.com>
The Julipedia - http://julipedia.blogspot.com/
The NetBSD Project - http://www.NetBSD.org/