From owner-freebsd-hackers Tue Jun 25 14: 8:12 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 4D7F737B40E for ; Tue, 25 Jun 2002 14:06:34 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 1F7C1AE2AC; Tue, 25 Jun 2002 14:06:34 -0700 (PDT) Date: Tue, 25 Jun 2002 14:06:34 -0700 From: Alfred Perlstein To: Terry Lambert Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... Message-ID: <20020625210633.GQ53232@elvis.mu.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D18CDB2.151978F3@mindspring.com> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Terry Lambert [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