Date: Wed, 5 Oct 2011 12:26:04 +0300 From: Gleb Kurtsou <gleb.kurtsou@gmail.com> To: Olivier Smedts <olivier@gid0.org> Cc: "freebsd-fs@freebsd.org" <freebsd-fs@freebsd.org>, Ivan Voras <ivoras@freebsd.org> Subject: Re: is TMPFS still highly experimental? Message-ID: <20111005092603.GA1874@tops> In-Reply-To: <CABzXLYO-gRt6o6wrevEFwwtTneYiShYD9UbK=j0UUUBzVob5jA@mail.gmail.com> References: <alpine.GSO.1.10.1110011122030.882@multics.mit.edu> <CADLo83-s_3H8PbbxOPPxbe0m10U0U5JW-feB294dFs%2BQ3iTWvg@mail.gmail.com> <CAGMYy3ssi%2BkAuufDTHA1z6u7jRrZwRRkCCkcO94GHNGF9Rku_w@mail.gmail.com> <20111002020231.GA70864@icarus.home.lan> <CAGMYy3sCCxOiVqeP4PVbvxnpcyoyQZoL%2Bw3nY8STYnpUNfj6JQ@mail.gmail.com> <j6aorc$hf0$1@dough.gmane.org> <CAGMYy3tbMWU6JU1%2B%2B5XmzjZTrV1=oAgRaaDE3-=MMT73F_ojQQ@mail.gmail.com> <CABzXLYNLhP%2BYFvT5Sw=hKVF6d_Yvmt%2Be_QjH7ghX-2MyzS0wWA@mail.gmail.com> <CAGMYy3s7RrP8oWC%2BJYgSG3hU1EXgKmnf%2BWQRiE2CDu4bHuz3UA@mail.gmail.com> <CABzXLYO-gRt6o6wrevEFwwtTneYiShYD9UbK=j0UUUBzVob5jA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On (04/10/2011 16:19), Olivier Smedts wrote: > 2011/10/4 Xin LI <delphij@gmail.com>: > > On Mon, Oct 3, 2011 at 2:36 PM, Olivier Smedts <olivier@gid0.org> wrote: > > [...] > >> Try reducing the swap size to less than the RAM size. No "configuration > >> issue", try with some RAM + swap that should fit all. > > > > But it's not ZFS+tmpfs specific, it can happen anywhere when memory > > and swap is not sufficient.  Of course tmpfs and ZFS should play more > > well together but it's pretty much a "you get what you paid for" > > situation IMHO. > > But there's a problem in this configuration and when memory and swap > are sufficient (swap free, some RAM free). tmpfs size drops to 0 > because it does not seem to calculate the free size correctly. If > there is sufficient RAM (some RAM free), sufficient swap (all free) > but less swap than RAM, and wired memory usage is high (ZFS ARC), > tmpfs size drops to 0. Free RAM is a bit tricky with virtual memory and overcommit support all over the place. There are at least 3 memory hungry subsystems: buffer cache, ZFS ARC, tmpfs. For the first two there is defined maximum size and they can be shrunk in low memory situations. Tmpfs grows as much as it can trying to calculate "free" memory available. Another difference is that tmpfs can't be shrunk in low memory situation. I proposed a patch changing tmpfs memory allocation: - Define maximum file system size (RAM/2 by default) - Don't try to check if free memory available, check free swap instead and allocate more aggressively, i.e. allocate until swap or file system limit is reached. Patch: http://marc.info/?l=freebsd-fs&m=129747367322954&w=2 https://github.com/glk/freebsd-head/tree/tmpfs Thanks, Gleb. > > One thing I can not yet reproduce, but sounds like a serious issue is > > that when system have sufficient RAM available, ZFS reports 0 in free > > space...  If there is a test case for that then that's definitely > > something we need to solve sooner. > > > > Cheers, > > -- > > Xin LI <delphij@delphij.net> https://www.delphij.net/ > > FreeBSD - The Power to Serve! Live free or die > > > > -- > Olivier Smedts                         _ >                     ASCII ribbon campaign ( ) > e-mail: olivier@gid0.org    - against HTML email & vCards X > www: http://www.gid0.org  - against proprietary attachments / \ > >  "Il y a seulement 10 sortes de gens dans le monde : >  ceux qui comprennent le binaire, >  et ceux qui ne le comprennent pas." > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111005092603.GA1874>