tmpfs is zero bytes (no free space), maybe a zfs bug?
kostikbel at gmail.com
Sun Jan 30 11:09:23 UTC 2011
On Wed, Jan 19, 2011 at 05:27:38PM +0100, Ivan Voras wrote:
> On 19 January 2011 16:02, Kostik Belousov <kostikbel at 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
> ? 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.
> Do you think that there is something which can be done as a band-aid
> without a major modification to tmpfs?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20110130/6f21744c/attachment.pgp
More information about the freebsd-stable