Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Jun 2002 00:25:09 -0700
From:      Alfred Perlstein <bright@mu.org>
To:        Terry Lambert <tlambert2@mindspring.com>
Cc:        Patrick Thomas <root@utility.clubscholarship.com>, freebsd-hackers@freebsd.org
Subject:   Re: tunings for many httpds...
Message-ID:  <20020625072509.GJ53232@elvis.mu.org>
In-Reply-To: <3D17DBC1.351A8A35@mindspring.com>
References:  <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com>

next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert2@mindspring.com> [020624 19:58] wrote:
> Alfred Perlstein wrote:
> > * Terry Lambert <tlambert2@mindspring.com> [020624 19:17] wrote:
> > >
> > > System V shared memory is allocated out of KVA space (annoying,
> > > but true).
> > 
> > You keep saying this but the backing object allocated for sysvshm
> > is taken from either an OBJT_PHYS or OBJT_SWAP object.
> 
> Uh, it's only ever an OBJT_SWAP; see line 532 of kern/sysv_shm.c.

Your sources seem to be really out of date...

Depending on the sysctl 'shm_use_phys' either an OBJT_PHYS or OBJT_SWAP
is allocated:

    656         if (shm_use_phys) {
    657                 shm_handle->shm_object =
    658                     vm_pager_allocate(OBJT_PHYS, 0, size, VM_PROT_DEFAUL        T, 0); 
    659         } else {
    660                 shm_handle->shm_object = 
    661                     vm_pager_allocate(OBJT_SWAP, 0, size, VM_PROT_DEFAUL        T, 0);
    662         }

> > At what point does it eat KVA that is other than for the backing
> > data structures?
> 
> It eats address space, not RAM.  And even if the mappings are not
> active (which they usually are, because of LRU and processes
> accessing them shared), the pages containing the page table entries
> for each process are themselves not swappable; anything with a
> large VSZ is going to eat 1/4k pages in KVA there, too.
> 
> Ask yourself where a shared memory segment lives when it's not in
> attached to one process address space, prior to you ipcrm'ing it.
> It has to remain referenced so it isn't reclaimed.

Yes, but not mapped into the kernel's address space right? right???

-- 
-Alfred Perlstein [alfred@freebsd.org]
'Instead of asking why a piece of software is using "1970s technology,"
 start asking why software is ignoring 30 years of accumulated wisdom.'
Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/

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?20020625072509.GJ53232>