From owner-freebsd-hackers Tue Jun 25 0:26:11 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 944FF37B48A for ; Tue, 25 Jun 2002 00:25:10 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id BF3BBAE163; Tue, 25 Jun 2002 00:25:09 -0700 (PDT) Date: Tue, 25 Jun 2002 00:25:09 -0700 From: Alfred Perlstein To: Terry Lambert Cc: Patrick Thomas , freebsd-hackers@freebsd.org Subject: Re: tunings for many httpds... Message-ID: <20020625072509.GJ53232@elvis.mu.org> References: <20020624151650.I68572-100000@utility.clubscholarship.com> <3D17D27A.11E82B2B@mindspring.com> <20020625022238.GH53232@elvis.mu.org> <3D17DBC1.351A8A35@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3D17DBC1.351A8A35@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 [020624 19:58] wrote: > Alfred Perlstein wrote: > > * Terry Lambert [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