Date: Mon, 7 Feb 2011 17:44:06 +0200 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-fs@freebsd.org, freebsd-stable@freebsd.org Subject: Re: tmpfs is zero bytes (no free space), maybe a zfs bug? Message-ID: <20110207154406.GA28877@tops.skynet.lt> In-Reply-To: <AANLkTikY1GHVmoTxTdwbnOERHV1zgvs5k4WXYY6irWeZ@mail.gmail.com> 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> <20110207133748.GA16327@tops.skynet.lt> <AANLkTikY1GHVmoTxTdwbnOERHV1zgvs5k4WXYY6irWeZ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (07/02/2011 15:35), Ivan Voras wrote:
> On 7 February 2011 14:37, Gleb Kurtsou <gleb.kurtsou@gmail.com> wrote:
>
> > It's up to user to mount tmpfs filesystems of reasonable size to prevent
> > resource exhaustion. Anyway, enormously large tmpfs killing all your
> > process is not the way to go.
>
> Of course not, but as I see it (from admin perspective), tmpfs should
> behave as close to regular processes in consuming memory as possible
> (where possible; obviously it cannot be subject to the OOM killer :)
> ).
Here is key difference it's not subject to be killed by OOM killer. Thus
exhausting all resource for real. I propose to enforce specifying upper
limit of filesystem size by user.
> The problem described in this thread is that there is enough memory in
> various lists and tmpfs still reports "0 bytes free". See my message:
> the machine had more than 8 GB of "free" memory (reported by "top")
> and still "0 bytes free" in tmpfs - and that's not counting inactive
> and other forms of used memory which could be freed or swapped out
> (and also not counting swap).
That's because tmpfs incorrectly checks how much memory is available
including both swap and ram. In VM world that's not so easy.
> By "as close to regular processes in consuming memory" I mean that I
> would expect tmpfs to allocate from the same total pool of memory as
> processes and be subject to the same mechanisms of VM, including swap.
> If that is not possible, I would (again, as an admin) like to extend
> the tmpfs(5) man page and other documentation with information about
> what types of memory will and will not count towards available to
> tmpfs.
>
> > Unless there are objections, I'm planning to do the following:
> >
> > 1. By default set tmpfs size to max(all swap/2, all memory/2) and print
> > warning that filesystem size should be specified manually.
> > Max(swap/2,mem/2) is used as a band-aid for the case when no swap is setup.
>
> You mean as a reservation, maximum limit or something else? If a tmpfs
> with "size" of e.g. 16 GB is configured, will the memory be
> preallocated? wired?
Memory in tmpfs is allocated/freed as needed, there is no preallocated
or reserved memory/swap. It already behaves the way you've described.
I'm against preallocating or reserving memory.
There is ramfs in linux that does preallocation, but it looks
deprecated.
> I don't think there should be default hard size limits to tmpfs - it
> should be able to hold sudden bursts of large temp files (using swap
> if needed), but that could be achieved by configuring a tmpfs whose
> size is RAM+swap if the memory is not preallocated so not a big
> problem.
But there is one in Linux (Documentation/filesystems/tmpfs.txt):
59 size: The limit of allocated bytes for this tmpfs instance. The
60 default is half of your physical RAM without swap. If you
61 oversize your tmpfs instances the machine will deadlock
62 since the OOM handler will not be able to free that memory.
That's actually what I've proposed: size=mem/2 vs size=max(mem/2,swap/2)
Limit should be there not to panic the system.
> > 3. Remove "live" filesystem size checks, i.e. do not depend on
> > free/inact memory.
>
> I'm for it, if it's possible in the light of #1
>
> > 2. Add support for resizing tmpfs on the fly:
> > mount -u -o size=<newsize> /tmpfs
>
> ditto.
It's trivial. If it can be resized, change maxsize in struct, fail
otherwise.
> > Reserving swap for tmpfs might not be what user expects: generally I use
> > tmpfs for work dir for building ports, it's unused most of the time.
>
> It looks like we think the opposite of it :) I would like it to be
> swapped out if needed, making room for running processes etc. as
> regular VM paging algorithms decide. Of course, if that could be
> controlled with a flag we'd both be happy :)
Perhaps there is a bit of misunderstanding, it will be swapped out, will
behave exactly as it does now, but will have sane default filesystem
size limit by default, will change semantics of calculating available
memory: I want it to try hard to allocate memory unless filesystem
limit is hit, failing only if there is clearly memory shortage (as I
said, it is for user to properly configure it).
> > btw, what linux and opensolaris do when available mem/swap gets low due
> > to tmpfs and how filesystem size determined at real-time?
>
> There's some information here: http://en.wikipedia.org/wiki/Tmpfs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110207154406.GA28877>