From owner-freebsd-current@FreeBSD.ORG Tue Nov 27 00:37:34 2007 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3B83216A41B for ; Tue, 27 Nov 2007 00:37:34 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (casselton.net [63.165.140.2]) by mx1.freebsd.org (Postfix) with ESMTP id E58D413C4DD for ; Tue, 27 Nov 2007 00:37:33 +0000 (UTC) (envelope-from tinguely@casselton.net) Received: from casselton.net (localhost [127.0.0.1]) by casselton.net (8.13.8/8.13.8) with ESMTP id lAR0bVJv050709; Mon, 26 Nov 2007 18:37:31 -0600 (CST) (envelope-from tinguely@casselton.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=casselton.net; s=ccnMail; t=1196123851; bh=TNSN6prCF75xUzAv/d9u7PUFCFyhjyOA8NArN8h dMmU=; h=Date:From:Message-Id:To:Subject:In-Reply-To; b=l3D6ba+iyQW yIaQhYKmlqXIgqlRmS5TfJIWmsQ9HwTOAWzVxK+FBkHuT7aSUuYn/sHJhuUs5mYqjSz k4cGlu8xCANo94+QsAReROP5DgOj4kLUR7riV8IiQXUYNUzAFv1eRjn00faaOSDLi2K DsUc8Le19elepTI8XXiMN4ge2w= Received: (from tinguely@localhost) by casselton.net (8.13.8/8.13.8/Submit) id lAR0bUuk050708; Mon, 26 Nov 2007 18:37:30 -0600 (CST) (envelope-from tinguely) Date: Mon, 26 Nov 2007 18:37:30 -0600 (CST) From: Mark Tinguely Message-Id: <200711270037.lAR0bUuk050708@casselton.net> To: freebsd-current@freebsd.org, mandrews@bit0.com In-Reply-To: <20071126160422.K82868@mindcrime.int.bit0.com> Cc: Subject: Re: vm.pmap.shpgperproc and Apache X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2007 00:37:34 -0000 > (This is about 7.0-BETA3 amd64) > > Can someone explain to someone who isn't a VM guru exactly what > vm.pmap.shpgperproc does? In non-technical terms, shpgperproc tells the OS a rough guess of how many pages will be shared between processes. The pv_entry_max is generated by multiplying shpgperproc by the maximum number of processes (maxproc) that was compiled into the kernel and adjusts for the page count. If maxproc was not hardcoded, then maxproc is also calculated based on the number of pages available in the computer When processes shares a physical page, each process may have a different virtual address for the page. The OS maintains a list of all the processes that are sharing the managed physical page and virtual address in that process. This structure also keeps a list of all the managed pages that are currently being used by this process. The structure that make up these lists is called a pv_entry. The new "chunked" pv_entry in FreeBSD 7 and 8 for the amd64/i386 architectures is very space efficient and IMO could tolerate higher shpgperproc/pv_entry_max limits. Raising the pv_entry_max too high, the problem will be getting a page for the pv_entry chunk, as well as getting physical page to share. More memory and increasing the pv_entry limits will help you avoid this problem. --Mark Tinguely