Date: Tue, 25 Jun 2002 14:06:34 -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: <20020625210633.GQ53232@elvis.mu.org> In-Reply-To: <3D18CDB2.151978F3@mindspring.com> References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> <20020625072509.GJ53232@elvis.mu.org> <3D18CDB2.151978F3@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Terry Lambert <tlambert2@mindspring.com> [020625 13:08] wrote: > > > > > 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??? > > Not for OBJT_PHYS, it seems: > > * Note: PG_UNMANAGED (used by OBJT_PHYS) indicates that the page is > * not under PV management but otherwise should be treated as a > * normal page. Pages not under PV management cannot be paged out > * via the object/vm_page_t because there is no knowledge of their > * pte mappings, nor can they be removed from their objects via > * the object, and such pages are also not on any PQ queue. > > Looks like it just eats physical memory. Which is still not mapped in kernel memory. > If you look at the commit message on version 1.48, you'll see that > without this option specified by the user, it eats KVA space, since > it eats KVM. The OBJT_PHYS was added specifically to support not > eating KVA space (by Peter, for Oracle, according to the comment). I don't need this lesson, I'm the one that fixed this option to work with multiple shared segments.... :) This is also the _default_ for how solaris manages sysv segments, although it would be nice if we could get the OBJT_PHYS stuff to use 4meg pages (unless someone already did that?)... Anyhow, I'm glad we corrected your misconception and we now have a more accurate understanding of how this system works. -Alfred 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?20020625210633.GQ53232>