Date: Thu, 19 Nov 1998 15:59:23 +0000 From: David Beck <DBECK@ludens.elte.hu> To: David Greenman <dg@root.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: SYSV Semaphores & mmap problems Message-ID: <Pine.VMS.3.91-vms-b4.981119154901.1109A-100000@ludens.elte.hu> In-Reply-To: <199811191440.GAA26690@root.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 19 Nov 1998, David Greenman wrote:
> Date: Thu, 19 NOV 1998 06:40:14 -0800
> From: David Greenman <dg@root.com>
> To: David Beck <DBECK@ludens.elte.hu>
> Cc: freebsd-hackers@FreeBSD.ORG
> Subject: Re: SYSV Semaphores & mmap problems
>
> >2., My freebsd box rebooted after I managed to run a multi-process
> > server program which serves a readonly memory database mmaped by all
> > the running 'memory server' instnaces. The size of the db is about
> > 20 Megs. It is an ordered array of key/value pairs and the program
> > actually using a binary search on it. After some investigation
> > I found that this came from these lines in i386/i386/pmap.c:
> >
> > 1461 if (!TAILQ_FIRST(&pv_freelist))
> > 1462 panic("get_pv_entry: cannot get a pv_entry_t");
> >
> > This really makes me wondering at first why does the kernel
> > reboot the whole system instead of signaling the process ?
> > Next, I'm wondering if there are any strategies to change this pv
> > interface in the future or it is the time to start hacking :) ?
>
> The panic is caused by running out of "pv entries", which are used in
> physical-to-virtual translations by the kernel. This is happening because
> you are running a large number of very large processes that all share the
> same address space and the default number of pv entries is inadequate for
> that. You can increase this with the "PMAP_SHPGPERPROC=<n>" kernel option,
> but be careful about how you set <n>. The default is 200; I'd try doubling
> it and at the same time decrease the maximum number of processes (via
> maxusers - maxproc is 16*maxusers). The problem you are want to avoid is
> consuming too much kernel virtual memory with all of the pv entries which
> will cause other problems if you run out of KVM.
>
The idea basically is to serve a huge database from a PC for cheap.
For this reason we want to maximize the database size as big as a PC
hardware can support . This can be something like 1 gig.
Do you think that this kernel tuning can solve this problem ? I beleive
that a more general approach would be better :)
On the other hand I actually can solve the problem by creating a
multithreaded version and simply malloc the needed space ....
There is still the issue that I beleive that the kernel really
shouldn't panic at a situation like this ...
David.
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?Pine.VMS.3.91-vms-b4.981119154901.1109A-100000>