Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Jun 2002 23:24:09 -0700
From:      Peter Wemm <peter@wemm.org>
To:        Patrick Thomas <root@utility.clubscholarship.com>
Cc:        Terry Lambert <tlambert2@mindspring.com>, Alfred Perlstein <bright@mu.org>, freebsd-hackers@FreeBSD.ORG
Subject:   Re: tunings for many httpds... 
Message-ID:  <20020626062409.C11ED3811@overcee.wemm.org>
In-Reply-To: <20020625230407.B68572-100000@utility.clubscholarship.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
Patrick Thomas wrote:
> 
> > Incidently, looking at the PV entry angle for a moment.  Suppose you
> > create a 1GB sysvshm (pageable) segment.  That's 262144 pages.  Mapping thi
    s
> > once means you consume 262144 PV entries.  At 28 bytes each, that is
> > about 7.3MB of KVM.  Now, fork this process 300 times.  The numbers become
> > 78643200 PV entries taking up about 2.2GB of PV entries that would like to 
    fit
> > in the 1G KVA space.  We dont even nearly have a way to fit all this in.
> >
> > This is the killer reason for SHM_PHYS stuff.  It avoids the PV load which
> > has to fit into a single confined space.  The cost of the page table pages
> > sucks, but at least that is spread over the VM space of 300 processes.
> 
> Ok, I'm confused now - so I understood you to originally say that SHM does
> not eat into KVA regardless of whether I set the kern.ipc.shm_use_phys to
> '1' or not.
> 
> This leads me to conclude that setting that sysctl to 1 will probably not
> be the magic bullet to stop my system from inexplicably halting. (my
> system with greatly (4x) increased SHM/SEM/etc. settings)
> 
> But now in this post ... are you saying that from the "PV entry angle"
> that KVA _is_ sometimes used for SHM, when we create a pageable segment ?
> 
> Or are you just providing a thought experiment and pointing out that if it
> _were_ done this way then XYZ bad things would occur ?

PV entries are normally used for user virtual mapping space.  Be it mmap,
sysvshm, whatever.  Massive sharing uses an additional set of PV entries
for each copy shared even though the same pages are used in both processes.
This can add up, eg: when you have large (1G-ish) mappings mapped several
hundred times on *pageable* space.

No, SHM does not eat into KVA for the SHM data pages themselves.

The use_phys effectively turns the data pages into un-pageable (ie: cannot
ever be swapped out to disk, no matter what) space so that PV entries are
not used either.

We run into these problems at work with large mmap segments.  a 1.5 to 2GB
file mapped into 200 apaches will bring a machine to its knees.

Anyway, if you have a single process in an event loop instead of an apache
style massive-fork model, then you do not hit this problem at all.

Cheers,
-Peter
--
Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com
"All of this is for nothing if we don't go to the stars" - JMS/B5


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?20020626062409.C11ED3811>