Date: Mon, 03 Oct 2011 21:10:42 +0200 From: Attila Nagy <bra@fsn.hu> To: d@delphij.net Cc: Adrian Chadd <adrian@freebsd.org>, freebsd-fs@freebsd.org, delphij@freebsd.org, Xin LI <delphij@delphij.net> Subject: Re: is TMPFS still highly experimental? Message-ID: <4E8A08B2.1010403@fsn.hu> In-Reply-To: <4E8A0232.1020005@delphij.net> References: <CAOfDtXMm9K_fbOmvG2gvXxDfKakkgpPt9MLifqDxa4wCibMExg@mail.gmail.com> <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> <4E899C8E.7040305@fsn.hu> <4E89ED58.6020104@delphij.net> <4E8A00BF.5000508@fsn.hu> <4E8A0232.1020005@delphij.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/03/2011 08:42 PM, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 10/03/11 11:36, Attila Nagy wrote: >> On 10/03/2011 07:14 PM, Xin LI wrote: >>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>> >>> Hi, Attila, >>> >>> On 10/03/11 04:29, Attila Nagy wrote: >>>> For me, the bug is still here: $ uname -a FreeBSD b 8.2-STABLE >>>> FreeBSD 8.2-STABLE #5: Wed Sep 14 15:01:25 CEST 2011 >>>> root@buildervm:/data/usr/obj/data/usr/src/sys/BOOTCLNT amd64 $ >>>> df -h /tmp Filesystem Size Used Avail Capacity Mounted >>>> on tmpfs 0B 0B 0B 100% /tmp >>>> >>>> I have no swap configured. The machine has 64 GB RAM. >>>> vm.kmem_size=60G; vfs.zfs.arc_max=55G; vfs.zfs.arc_min=20G >>> This sounds like a configuration issue. Running without swap is >>> not recommended anyways. >> I guess it depends on the workload. In general, you are possibly >> right, but if you need predictable response times and you can >> tolerate dying processes, swapping may not be the right thing to >> do. > Well, in that case one will have to tolerate tmpfs have no page to > allocate (note that it does need to reserve some pages for system use) > at this point. Currently it's working like a credit line -- use it > here and you can't use it elsewhere, e.g. if user process used it then > tmpfs can't use it... Sure, but we are talking here about ARC, which is a cache. I guess tmpfs work quite OK with UFS, where it will shrink its cache space. BTW, I don't care if tmpfs shows 2 GB free space when there is (>)2 GB, but currently I have: Mem: 564M Active, 3091M Inact, 55G Wired, 129M Cache, 71M Buf, 2957M Free and: Filesystem Size Used Avail Capacity Mounted on tmpfs 0B 0B 0B 100% /tmp That's the first problem. (the second could be to shrink ARC from tmpfs-land if needed) > I think the only solution we can have here is to teach tmpfs about > "dedicated reserve for tmpfs" so it pre-allocate a few pages that can > not be reused elsewhere? E.g. create a budget that make this part of > memory "tmpfs fund" :) > > There is md for that. Sure, it's harder, and using UFS (or any other FS) on md seems to be a waste of resources. For me it would be quite enough if tmpfs wouldn't loose all its space when there is free memory.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E8A08B2.1010403>