From owner-freebsd-hackers Sat May 11 13:13:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from screech.weirdnoise.com (209-128-78-198.BAYAREA.NET [209.128.78.198]) by hub.freebsd.org (Postfix) with ESMTP id 0607137B406 for ; Sat, 11 May 2002 13:13:38 -0700 (PDT) Received: from screech.weirdnoise.com (localhost [127.0.0.1]) by screech.weirdnoise.com (8.11.6/8.9.3) with ESMTP id g4BKFt390577 for ; Sat, 11 May 2002 13:15:55 -0700 (PDT) Message-Id: <200205112015.g4BKFt390577@screech.weirdnoise.com> X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4 To: freebsd-hackers@freebsd.org Subject: Memory and Reality Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 11 May 2002 13:15:55 -0700 From: Ed Hall 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 At Yahoo! we use a lot of shared memory, both in the form of .so's and for IPC. It would be very useful to be able to accurately measure the amount of shared and private memory associated with a process, the number of references to a given shared memory object, resident vs. non- resident pages, and so forth. Determining just what is shared and by how many is the hardest part. When I asked Peter Wemm about sussing out this sort of info from proc/*/map, he made some comments about the difficulty of knowing what actually was shared and what wasn't, how the refcounts aren't exactly what one might think they are, and so forth. The same sort of ambiguity seemed to exist regarding just what is resident (with the term defined as "in RAM with no need to retrieve from secondary storage") and what isn't. Are things really this bad? Is there a tool out there that can make sense of FreeBSD's memory state with more accuracy and detail than "ps" or "top"? This is a serious issue. Whether this is exclusively a FreeBSD problem or not, developers tend to see it that way. -Ed To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message