From owner-freebsd-hackers@FreeBSD.ORG  Tue Feb  8 21:05:21 2011
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
Delivered-To: freebsd-hackers@freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id 621C510656A4;
	Tue,  8 Feb 2011 21:05:21 +0000 (UTC)
	(envelope-from rwatson@freebsd.org)
Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42])
	by mx1.freebsd.org (Postfix) with ESMTP id 39E248FC17;
	Tue,  8 Feb 2011 21:05:21 +0000 (UTC)
Received: from [10.255.241.24] (192-5-67-11.sri.com [192.5.67.11])
	by cyrus.watson.org (Postfix) with ESMTPSA id 6DAB846B23;
	Tue,  8 Feb 2011 16:05:20 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset=us-ascii
From: "Robert N. M. Watson" <rwatson@freebsd.org>
In-Reply-To: <201102081547.37650.jhb@freebsd.org>
Date: Tue, 8 Feb 2011 13:05:19 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <92A3111D-AE7A-46DA-BEB7-A2D315097F63@freebsd.org>
References: <iirce4$urj$1@dough.gmane.org>
	<AANLkTikNw4G7MDHwCAmxfzFGUBxQb1S9pUjTM_-g3K+y@mail.gmail.com>
	<alpine.BSF.2.00.1102081825370.12092@fledge.watson.org>
	<201102081547.37650.jhb@freebsd.org>
To: John Baldwin <jhb@freebsd.org>
X-Mailer: Apple Mail (2.1082)
Cc: alc@freebsd.org, freebsd-hackers@freebsd.org,
	Ivan Voras <ivoras@freebsd.org>
Subject: Re: Analyzing wired memory?
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Feb 2011 21:05:21 -0000


On 8 Feb 2011, at 12:47, John Baldwin wrote:

> What I have used is a 'kvm' command in my kgdb scripts, but it is not =
nearly
> that granular.  It is also a view of the virtual address space =
(similar to
> procstat -v), not a view of the physical address space.  I have found =
it
> useful though (sample output from my desktop running 7-ish):
>=20
> (kgdb) kvm
> ffffff8000000000 - ffffff800000f000 kmem_alloc() / contigmalloc()
> ffffff800000f000 - ffffff8000021000 AP stacks
> ffffff8000021000 - ffffff80000a3000 kmem_alloc_nofault() =
(kstack/mapdev)
> ffffff80000a3000 - ffffff80000c3000 kmem_alloc() / contigmalloc()
...
> (The various objects inserted directly into the kernel_map are likely =
from
> the nvidia driver.)
>=20
> The 'kvm' command in my gdb script is mostly MI, but some bits are MD =
such as
> the code to handle the 'AP stacks' region.

This is the sort of thing I have in mind, although passing a bit more =
information down through the allocators to VM so that it can expose that =
information more readily to userspace. Really it's just an information =
management problem -- how to get the information in the right place, and =
also not have it be too overwhelming. My temptation would be to simply =
export this data via the same procstat VM sysctls we already have, but =
for process 0. We have storage for a path there already, although my =
temptation would be to add a new mapping type to the procstat =
enumeration to capture the idea of kernel memory, so that the names =
aren't "paths" from an API perspective, but strings.

Robert=