Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 01 Feb 2011 10:49:23 +0100
From:      Attila Nagy <bra@fsn.hu>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        freebsd-fs@freebsd.org, freebsd-stable@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject:   Re: tmpfs is zero bytes (no free space), maybe a zfs bug?
Message-ID:  <4D47D723.6000106@fsn.hu>
In-Reply-To: <20110130110918.GR2518@deviant.kiev.zoral.com.ua>
References:  <4D36A2CF.1080508@fsn.hu> <20110119084648.GA28278@icarus.home.lan>	<4D36B85B.8070201@fsn.hu> <ih6f1d$u16$1@dough.gmane.org>	<20110119150200.GY2518@deviant.kiev.zoral.com.ua>	<AANLkTinPZ8jP5yX2se5LLaBYP1dpbEAhX-u7Wr0NAGz4@mail.gmail.com> <20110130110918.GR2518@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
On 01/30/11 12:09, Kostik Belousov wrote:
> On Wed, Jan 19, 2011 at 05:27:38PM +0100, Ivan Voras wrote:
>> On 19 January 2011 16:02, Kostik Belousov<kostikbel@gmail.com>  wrote:
>>
>>>> http://people.freebsd.org/~ivoras/diffs/tmpfs.h.patch
>>>>
>>>> I don't think this is a complete solution but it's a start. If you can,
>>>> try it and see if it helps.
>>> This is not a start, and actually a step in the wrong direction.
>>> Tmpfs is wrong now, but the patch would make the wrongness even bigger.
>>>
>>> Issue is that the current tmpfs calculation should not depend on the
>>> length of the inactive queue or the amount of free pages. This data only
>>> measures  the pressure on the pagedaemon, and has absolutely no relation
>>> to the amount of data that can be put into anonymous objects before the
>>> system comes out of swap.
>>>
>>> vm_lowmem handler is invoked in two situations:
>>> - when KVA cannot satisfy the request for the space allocation;
>>> - when pagedaemon have to start the scan.
>>> None of the situations has any direct correlation with the fact that
>>> tmpfs needs to check, that is "Is there enough swap to keep all my
>>> future anonymous memory requests ?".
>>>
>>> Might be, swap reservation numbers can be useful to the tmpfs reporting.
>>> Also might be, tmpfs should reserve the swap explicitely on start, instead
>>> of making attempts to guess how much can be allocated at random moment.
>> Thank you for your explanation! I'm still not very familiar with VM
>> and VFS. Could you also read my report at
>> http://www.mail-archive.com/freebsd-current@freebsd.org/msg126491.html
>> ? I'm curious about the fact that there is lots of 'free' memory here
>> in the same situation.
> This is another ugliness in the dynamic calculation. Your wired is around
> 15GB, that is always greater then available swap + free + inactive.
> As result, tmpfs_mem_info() always returns 0.
> In this situation TMPFS_PAGES_MAX() seems to return negative value, and
> then TMPFS_PAGES_AVAIL() clamps at 0.
>
Well, if nobody can take care of this now, could you please state this 
in the BUGS section of the tmpfs man page?

Thanks,



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D47D723.6000106>