Date: Sat, 5 May 2007 10:46:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: John-Mark Gurney <gurney_j@resnet.uoregon.edu> Cc: pluknet <pluknet@gmail.com>, freebsd-stable@freebsd.org, "Marc G. Fournier" <freebsd@hub.org> Subject: Re: swap zone exhausted, increase kern.maxswzone Message-ID: <200705051746.l45HkuUK096770@apollo.backplane.com> References: <5580F93A753EBAEF71B41EE7@ganymede.hub.org> <20070505160655.GA847@xor.obsecurity.org> <F7A69B1C2C53E12D2A2DCB1A@ganymede.hub.org> <a31046fc0705050935t631d034bm152fdd949565f3c2@mail.gmail.com> <576837AA4FFCB91BF5B92A61@ganymede.hub.org> <20070505171806.GK17958@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Basically maxswzone is the amount of KVM the kernel is willing to
use to store 'struct swblock' structures.
These are the little structures that are stuck onto VM objects and
specify which pages in the VM object(s) correspond to which pages
of swap, for any swapped out data that no longer has a vm_page_t.
It should be almost impossible to run out. Each structure can handle
16 contiguous swap block assignments in the VM object. Pages in
VM objects tend to get swapped out in large linear swaths and the
dynamic nature of paging tends to enforce this even if things are
a bit chunky initially. So running out should just never happen.
The only thing I can think of is if a machine has a tiny, tiny amount
of ram and a huge amount of swap. e.g. like 64M of ram and 2G of swap,
and actually tries to use it all. The default KVM reservation is based
on physical memory, I think. Otherwise, it just shouldn't happen.
I see that the code in FreeBSD is using UMA now, I would double check
that it is actually calculating the proper amount of space allowed to be
allocated. Maybe you have a leak somewhere.
Note that swap interactions have to operate in low-memory situations.
Make sure UMA isn't gonna have a meltdown if the system is running low
on freeable VM pages.
-Matt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200705051746.l45HkuUK096770>