Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Feb 2011 13:05:19 -0800
From:      "Robert N. M. Watson" <rwatson@freebsd.org>
To:        John Baldwin <jhb@freebsd.org>
Cc:        alc@freebsd.org, freebsd-hackers@freebsd.org, Ivan Voras <ivoras@freebsd.org>
Subject:   Re: Analyzing wired memory?
Message-ID:  <92A3111D-AE7A-46DA-BEB7-A2D315097F63@freebsd.org>
In-Reply-To: <201102081547.37650.jhb@freebsd.org>
References:  <iirce4$urj$1@dough.gmane.org> <AANLkTikNw4G7MDHwCAmxfzFGUBxQb1S9pUjTM_-g3K%2By@mail.gmail.com> <alpine.BSF.2.00.1102081825370.12092@fledge.watson.org> <201102081547.37650.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

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=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?92A3111D-AE7A-46DA-BEB7-A2D315097F63>