Subject: Re: /dev on tmpfs problem
To: None <email@example.com>
From: Julio M. Merino Vidal <firstname.lastname@example.org>
Date: 11/13/2005 23:13:40
On 11/13/05, Daniel Carosone <email@example.com> 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 =
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=
fix this issue... (which unfortunately is very important to get fixed to h=
a usable tmpfs on swapless machines).
Julio M. Merino Vidal <firstname.lastname@example.org>
The Julipedia - http://julipedia.blogspot.com/
The NetBSD Project - http://www.NetBSD.org/