On Mon, Apr 02, 2012 at 01:31:19PM +0300, Gleb Kurtsou wrote: > ... > > > In any case, effective maximum usable size for tmpfs involves SIZE_MAX > > > (~4G) & PAGE_SIZE (4K, in my case). > > size_t is 64-bit on 64-bit archs. OK. Still, the requirement that the "size" specification be in "bytes" is awkward (in my experience) -- and I was using i386. > > > * Even when I went ahead and created a tmpfs for /tmp, I'd get ENOSPC > > > whenever I tried to allocate anything on it -- until I dropped the > > > size specification to <2G (2**32). Well, 2GB for /tmp just wasn't at > > > all likely to be useful for my purposes in this case. > > Are you using ZFS alongside tmpfs? It should be fixed in 9-STABLE. I have not tried ZFS yet. I don't expect to do so unless I switch to amd64. > ... > > It seems there is only one switch which determines the size of the tmpfs > > in question (size) and there is no convenient way to say what amount of > > RAM is being used before using the swap space. I'd like to have at least > > a knob determining the limit of RAM being used. > > There is no way to force tmpfs to use given amount of RAM only. It's VM > subsystem that decides what pages to swap. Although some tweaking for VM > to prefer swapping tmpfs pages prior to process pages would be nice. > > You could try the patch attached. It adds support for size option suffixes > (like 1g) and introduces swap limit (part of the older patch, not sure > if it's any use). > > Patch is against 10-CURRENT. > Older version: https://github.com/glk/freebsd-head/commit/3bd8f7d > ... I'll plan to try this on a currrently-underutilized slice on my laptop, then -- thanks! :-) Peace, david -- David H. Wolfskill david_at_catwhisker.org Depriving a girl or boy of an opportunity for education is evil. See http://www.catwhisker.org/~david/publickey.gpg for my public key.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:25 UTC