Analyzing wired memory?

Robert N. M. Watson rwatson at freebsd.org
Tue Feb 8 21:05:21 UTC 2011


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):
> 
> (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.)
> 
> 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


More information about the freebsd-hackers mailing list