Subject: Re: /dev on tmpfs problem
To: None <email@example.com>
From: YAMAMOTO Takashi <firstname.lastname@example.org>
Date: 11/14/2005 09:57:37
> > because the desired size of tmpfs can not be calculated from
> > the total amount of memory.
> To me, its "all memory+swap not otherwise in use for something else,
> up to the -s limit if specified". As these things change, so does the
> size of tmpfs (as seen in df).
i don't think it works as a magic.
once tmpfs filled up all the memory+swap, even kernel will fail
to allocate memory. i'd say it's unusable.
i guess what you really want to know is "memory + swap - inuse - future_use".
and of course you can't estimate future_use in a mechanical way.
yes, there's the same problem for arbitrary anonymous memory.
it's what "oom killer" is for.
"oom removal of files" can work for tmpfs but i don't think
it's desirable. :-)
> > > If I use tmpfs with no backing swap, I have to recognise that I might
> > > fill my filecache memory with tmpfs files that can't be paged out, and
> > > thus starve myself of other cache or memory needs; I can use -s to
> > > limit the size allocated to tmpfs to help here, if I want.
> > you have to do so unless you have infinite amount of swap.
> Not at all.. The size of tmpfs is bounded by the size of swap (and
> other active allocations). I should even be able to remove some
> swapspace (if unallocated) and see the free space in /tmp drop.
> -s is a useful bound when the issue is competition between tmpfs and
> these other allocations. This is the reverse situation, because
> there's now competition for free space slop between file cache and
> tmpfs available space reporting.
sorry, i don't understand what you mean.