Date: Mon, 24 Jun 2002 12:14:55 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Patrick Thomas <root@utility.clubscholarship.com>, Nielsen <nielsen@memberwebs.com>, hackers@FreeBSD.ORG Cc: Terry Lambert <tlambert2@mindspring.com> Subject: Re: (jail) problem and a (possible) solution ? Message-ID: <200206241914.g5OJEttA096925@apollo.backplane.com> References: <20020622164732.L68572-100000@utility.clubscholarship.com> <3D158E12.CDB87171@mindspring.com>
index | next in thread | previous in thread | raw e-mail
Well, it should be noted that there are two things going on with swap.
What I adjusted was the size of the swap_zone, which holds swblocks.
These structures hold the VM->SWAP block mappings for things that are
swapped out. The swap zone eats a lot more KVA then the radix tree
holding the swap bitmaps.
The actual swap bitmaps are allocated from the M_SWAP malloc pool. These
allocations are based on NSWAP * (largest_single_swap_area). NSWAP
is usually 4.
Having a single 2GB swap area is therefore somewhat expensive, but still
nowhere near the size required to exhaust KVM (or even come close to
exhausting KVM). It is just as expensive as having 4 x 2GB swap areas
due to the way the bitmaps are allocated. The swap bitmaps eat around
2 bits per 4K block of swap so a single 2GB of swap will eat
2G/4K x 2 / 8 x NSWAP(4) = 0.5 MB of ram. Not very much.
But, getting back to the swblocks... these use a zone, SWAPMETA
(vmstat -z | less, search for SWAPMETA). The zone reserves KVA.
A machine with 2GB of real memory will typically reserve around 10 MB
of KVA to hold swblocks. Previously it reserved 20-40 MB of KVA which
really ate into available KVA. It should not be a problem now but
it's very easy for you to check. Multiply the size (160) against the
LIMIT and you will get the approximate KVA reservation being used
for the SWAPMETA zone.
--
Ok, history lesson over. Going over your original posting and the ps
you just posted from ddb> there is not enough information to make
any sort of diagnosis. It doesn't look like KVA exhaustion to me,
and the ps does not show any deadlocks. I'm not sure what is going
on. I think some more experimentation is necessary... e.g. breaking into
DDB after it deadlocks and doing a full 'ps' (don't leave anything out
this time), and potentially getting a kernel core dump (assuming you
compiled the kernel -g and have a kernel.debug lying around that we
can gdb the core against).
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206241914.g5OJEttA096925>