> > 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.

YAMAMOTO Takashi