Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 8 Feb 2011 15:47:37 -0500
From:      John Baldwin <jhb@freebsd.org>
To:        freebsd-hackers@freebsd.org
Cc:        alc@freebsd.org, Robert Watson <rwatson@freebsd.org>, Ivan Voras <ivoras@freebsd.org>
Subject:   Re: Analyzing wired memory?
Message-ID:  <201102081547.37650.jhb@freebsd.org>
In-Reply-To: <alpine.BSF.2.00.1102081825370.12092@fledge.watson.org>
References:  <iirce4$urj$1@dough.gmane.org> <AANLkTikNw4G7MDHwCAmxfzFGUBxQb1S9pUjTM_-g3K%2By@mail.gmail.com> <alpine.BSF.2.00.1102081825370.12092@fledge.watson.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday, February 08, 2011 1:27:22 pm Robert Watson wrote:
> 
> On Tue, 8 Feb 2011, Alan Cox wrote:
> 
> > On Tue, Feb 8, 2011 at 6:20 AM, Ivan Voras <ivoras@freebsd.org> wrote:
> >
> >> Is it possible to track by some way what kernel system, process or thread 
> >> has wired memory? (including "data exists but needs code to extract it")
> >>
> > No.
> >
> >
> >> I'd like to analyze a system where there is a lot of memory wired but not 
> >> accounted for in the output of vmstat -m and vmstat -z. There are no user 
> >> processes which would lock memory themselves.
> >>
> >> Any pointers?
> >>
> > Have you accounted for the buffer cache?
> 
> John and I have occasionally talked about making procstat -v work on the 
> kernel; conceivably it could also export a wired page count for mappings where 
> it makes sense.  Ideally procstat would drill in a bit and allow you to see 
> things at least at the granularty of "this page range was allocated to UMA".

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()
ffffff80000c3000 - ffffff80000c8000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80000c8000 - ffffff80000e8000 kmem_alloc() / contigmalloc()
ffffff80000e8000 - ffffff80000f2000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80000f2000 - ffffff8000200000 kmem_alloc() / contigmalloc()
ffffff8000200000 - ffffff8051da4000 kmem_map
ffffff8051da4000 - ffffff80523787e0 callouts
ffffff80523787e0 - ffffff80523a07e0 swbuf
ffffff80523a07e0 - ffffff80533f2000 buf
ffffff80533f2000 - ffffff806f5aa000 buffer_map + pager_map
ffffff806f5aa000 - ffffff806f9da000 exec_map
ffffff806f9da000 - ffffff8073b3b000 pipe_map
ffffff8073b3b000 - ffffff807534f000 kmem_alloc_nofault() (kstack/mapdev)
ffffff807534f000 - ffffff8076261000 kmem_alloc() / contigmalloc()
ffffff8076261000 - ffffff807626b000 kmem_alloc_nofault() (kstack/mapdev)
ffffff807626b000 - ffffff8077281000 kmem_alloc() / contigmalloc()
ffffff8077281000 - ffffff8077295000 kmem_alloc_nofault() (kstack/mapdev)
ffffff8077295000 - ffffff807729c000 kmem_alloc() / contigmalloc()
ffffff807729c000 - ffffff80772a6000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80772a6000 - ffffff80772ad000 kmem_alloc() / contigmalloc()
ffffff80772ad000 - ffffff80772b2000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80772b2000 - ffffff80772b9000 kmem_alloc() / contigmalloc()
ffffff80772b9000 - ffffff80772be000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80772be000 - ffffff80772d0000 kmem_alloc() / contigmalloc()
ffffff80772d0000 - ffffff80772d5000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80772d5000 - ffffff80772d9000 kmem_alloc() / contigmalloc()
ffffff80772d9000 - ffffff80772de000 kmem_alloc_nofault() (kstack/mapdev)
ffffff80772de000 - ffffff80772f6000 kmem_alloc() / contigmalloc()
ffffff80772f6000 - ffffff8077300000 kmem_alloc_nofault() (kstack/mapdev)
ffffff8077300000 - ffffff807730a000 kmem_alloc() / contigmalloc()
ffffff807730a000 - ffffff807730f000 kmem_alloc_nofault() (kstack/mapdev)
ffffff807730f000 - ffffff8077310000 kmem_alloc() / contigmalloc()
ffffff8077310000 - ffffff8077315000 kmem_alloc_nofault() (kstack/mapdev)
ffffff8077315000 - ffffff8077316000 kmem_alloc() / contigmalloc()
ffffff8077316000 - ffffff807733e000 kmem_alloc_nofault() (kstack/mapdev)
ffffff807733e000 - ffffff8079641000 swap zone
ffffff8079641000 - ffffff807988f000 kmem_alloc_nofault() (kstack/mapdev)
ffffff807988f000 - ffffff807989a000 kmem_alloc() / contigmalloc()
ffffff807989a000 - ffffff80798a5000 object 0xffffff000fbd20d8
ffffff80798a5000 - ffffff80798a6000 kmem_alloc() / contigmalloc()
ffffff80798a6000 - ffffff80798a7000 object 0xffffff000fa8c798
ffffff80798a7000 - ffffff80798b8000 kmem_alloc() / contigmalloc()
ffffff80798b8000 - ffffff80798b9000 object 0xffffff000fa8c798
ffffff80798b9000 - ffffff80798ba000 object 0xffffff000fa8c798
ffffff80798ba000 - ffffff80798bb000 object 0xffffff000fa8c798
ffffff80798bb000 - ffffff80798bc000 object 0xffffff000fa8c798
ffffff80798bc000 - ffffff80798cc000 kmem_alloc() / contigmalloc()
ffffff80798cc000 - ffffff80798cd000 object 0xffffff000fa8c798
ffffff80798cd000 - ffffff80798ce000 object 0xffffff000fa8c798
ffffff80798ce000 - ffffff80798e3000 kmem_alloc() / contigmalloc()
ffffff80798e3000 - ffffff80798e4000 object 0xffffff000f6965e8
ffffff80798e4000 - ffffff80798e5000 object 0xffffff000f6965e8
ffffff80798e5000 - ffffff80798e6000 object 0xffffff000f6965e8
ffffff80798e6000 - ffffff80798e7000 object 0xffffff000f6965e8
ffffff80798e7000 - ffffff80798e8000 object 0xffffff000f6965e8
ffffff80798e8000 - ffffff80798ea000 kmem_alloc() / contigmalloc()
ffffff80798ea000 - ffffff8079949000 kmem_alloc_nofault() (kstack/mapdev)
ffffff8079949000 - ffffff807994a000 kmem_alloc() / contigmalloc()
ffffff807994a000 - ffffff807994b000 object 0xffffff0060568af8
ffffff807994b000 - ffffff8079969000 kmem_alloc_nofault() (kstack/mapdev)
ffffff8079969000 - ffffff807996b000 ----
ffffff807996b000 - ffffff80799b0000 kmem_alloc() / contigmalloc()
ffffff80799b0000 - ffffff80799b1000 object 0xffffff00606caca8
ffffff80799b1000 - ffffff80799b2000 object 0xffffff00606caca8
ffffff80799b2000 - ffffff80799b6000 kmem_alloc() / contigmalloc()
ffffff80799b6000 - ffffff80799b7000 object 0xffffff0060568af8
ffffff80799b7000 - ffffff80799b8000 object 0xffffff0060568af8
ffffff80799b8000 - ffffff8079cbc000 kmem_alloc() / contigmalloc()
ffffff8079cbc000 - ffffff807aa0e000 kmem_alloc_nofault() (kstack/mapdev)
ffffff807aa0e000 - ffffffff80000000 ----
ffffffff80000000 - ffffffff808164e8 text/data/bss
ffffffff808164e8 - ffffffff81822000 bootstrap data

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

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201102081547.37650.jhb>