Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Mar 2003 15:54:13 -0800
From:      "Andrew Kinney" <andykinney@advantagecom.net>
To:        freebsd-hackers@freebsd.org
Subject:   increasing KVA_PAGES and broken pthreads
Message-ID:  <3E71FB25.27881.363E6F4@localhost>

next in thread | raw e-mail | index | archive | help
Hello,

I'm brand new to this list so feel free to tell me to search the 
archives if this question has already been answered.  I have already 
done some searching and only found limited and/or antiquated 
information on the subject, though, so I'm pretty sure this hasn't 
been addressed yet.

Does anyone know if a PR was ever submitted for the issue at:

http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg38532.html

I know from reading the thread that a patch was created and sent 
to this list.  Was that patch ever made a part of the CVS tree?  If 
so, what branch would I have to track to pick up that patch?  I'd like 
to avoid adding patches that CVSup will clobber later.

I've seen this same issue with FreeBSD 4.5-RELEASE running on 
a heavily loaded web/mail/database server with dual CPU and 4GB 
of RAM and 8GB of available swap (no swapping activity).  Setting 
KVA_PAGES=512 rather than the default 256 caused MySQL to 
die repeatedly with signal 6 as fast as it could respawn itself.  The 
MySQL daemon was compiled on another FreeBSD 4.x system 
and was part of a prepackaged application from a commercial 
vendor.

I've already tuned the system quite a bit to get around a lot of the 
"large memory" issues.  However, because of all the tuning to avoid 
running out of various kernel resources before we ran out of 
physical RAM, we're now running out of KVM or will very soon.  

%sysctl -a |grep kvm
vm.kvm_size: 1065353216
vm.kvm_free: 4194304
%sysctl kern.maxusers
kern.maxusers: 384  (the autoscale max)

In particular, we had to take PMAP_SHPGPERPROC up to 1500 
from the default of 200 due to the large amount of shared memory 
pages that Apache needs to do its job efficiently.  That puts KVM 
usage by PV Entries alone to nearly 300MB.  We were getting 
kernel panics every time we ran out of available PV Entries 
(vm.zone: PV ENTRY), so this was very necessary.  We also had 
to increase NMBCLUSTERS to 12800 (higher than the autoscale 
max).  This also put some pressure on free KVM.

We're now tracking RELENG_4_7 (FreeBSD 4.7-RELEASE + 
security fixes).  I haven't tried changing KVA_PAGES since version 
4.5 and I'm a little gun-shy on changing that particular tunable 
since it has so many potential application gotchas, like with 
pthreads.

The RELENG_4_7 CVS tree (updated yesterday) doesn't appear to 
have the patch mentioned in the thread I referenced in the URL at 
the beginning of my message.  Our version string for that file:

* $FreeBSD: src/lib/libc_r/uthread/uthread_init.c,v 1.23.2.7 2001/11/03 00:33:07 peter Exp $

IMHO, this issue could be a royal pain in the butt when I start 
working on quad processor systems with 32GB of RAM (not 
unrealistic at this company).  I'd like to stay with FreeBSD, but the 
issues with large memory support are rapidly becoming more 
prominent due to the *huge* memory systems in use here, with 
even larger memory systems on the way in the near future.  I came 
from the Linux camp (back when 2.0/2.2 kernels were the newest 
in use) and I don't want to have to go back, though I no longer have 
any clue how those boys handle large memory systems.  Maybe 
they're not any better in that department.  I just happen to like 
FreeBSD better and would prefer to stick with it if possible.

So, to recap my questions, what branch would I have to track to 
pick up that patch to pthreads?  If there is no branch with that 
patch, has a PR been submitted so it can eventually be included in 
the source?  If so, what is the PR number?  If not, what's the best 
way to submit a PR?

Thanks in advance for any assistance in this matter.




Sincerely,
Andrew Kinney
President and
Chief Technology Officer
Advantagecom Networks, Inc.
http://www.advantagecom.net


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E71FB25.27881.363E6F4>