Date: Sat, 01 Feb 2014 13:03:15 -0600 From: Richard Todd <rmtodd@servalan.servalan.com> To: Matthew Rezny <matthew@reztek.cz> Cc: freebsd-stable@freebsd.org Subject: Re: Tuning kern.maxswzone Message-ID: <x7d2j64pvw.fsf@ichotolot.servalan.com> In-Reply-To: <20140201070912.00007971@unknown> (Matthew Rezny's message of "Sat, 1 Feb 2014 07:09:12 %2B0100") References: <20140201070912.00007971@unknown>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Rezny <matthew@reztek.cz> writes:
> So, as best I can tell, the actual effective number used for
> kern.maxswzone is indeed approximately 8x available RAM. If there is
> some need to turn it down (using substantially less swap) then that is
> possible, but turning it up (as suggested by the warning message) is
> not possible. Setting any value higher does not appear to actually
Yeah, IIRC I ran into that when configing some VMs with
really big swap space for benefit of tmpfs. This is the quick hack I used
to get around that, you might give it a try.
# HG changeset patch
# Parent e4dd7df011139e2b224835aa6e330c90afcf9a55
patch swap_pager to unconditionally use maxswzone tunable if it is set -- helpful for our tbvm VMs with large swap space for tmpfs
diff -r e4dd7df01113 sys/vm/swap_pager.c
--- a/sys/vm/swap_pager.c Wed Feb 20 00:15:49 2013 -0600
+++ b/sys/vm/swap_pager.c Sat Feb 23 13:08:54 2013 -0600
@@ -546,7 +546,7 @@
* is typically limited to around 32MB by default.
*/
n = cnt.v_page_count / 2;
- if (maxswzone && n > maxswzone / sizeof(struct swblock))
+ if (maxswzone)
n = maxswzone / sizeof(struct swblock);
n2 = n;
swap_zone = uma_zcreate("SWAPMETA", sizeof(struct swblock), NULL, NULL,
Also,
> With /usr/src cleared (and after running fsck) I booted back into
> 10-PRERELEASE to try to fetch the 10-STABLE sources again. I started
> svnlite co and find it hung shortly thereafter. I tried a few times but
> each time I see it does a couple hundred files at best and just stops.
> When it stops, I can't login to another terminal. If I have a spare
> console logged in, I can't run anything. After a few tries, I manged to
> catch it where I had top running in one VT, started the checkout, and
> then switched back just in time. I never could even get top up with rm
> running (it probably blows over some limit faster). When the checkout
> hangs, the state of svnlite is "kmem a" according to top. I can only
> guess that is short for kmem alloc, I guess some syscall is waiting on
> an allocation that will never happen because something already is using
> or has leaked everything that could satisfy that allocation. It looks
> like activity on too many files within a short period runs something
> out.
No, it's just a new bit of debugging code that causes the system
to spend lots of CPU time verifying integrity of some of its internal data
structures, especially on wimpy hardware (e.g., my dual PII/400 box, which is
where I noticed this recently.) You'll find if you're patient that it isn't
a complete hang, it will actually get work done in between the debug passes.
Set sysctl debug.vmem_check=0 to disable the check. This is I think completely
independent from the maxswzone stuff, it's just you were seeing it for the
first time since the debug code in question was only recently added to
10-STABLE.
Richard
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?x7d2j64pvw.fsf>