From owner-freebsd-hackers@FreeBSD.ORG Tue Feb 8 18:57:04 2011 Return-Path: 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 583CC1065672 for ; Tue, 8 Feb 2011 18:57:04 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2F3E88FC18 for ; Tue, 8 Feb 2011 18:57:03 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 4600228F8C5; Tue, 8 Feb 2011 12:38:28 -0600 (CST) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 09lqL90dJ1+V; Tue, 8 Feb 2011 12:38:28 -0600 (CST) Received: from [10.209.194.7] (unknown [10.209.194.7]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh5.mail.rice.edu (Postfix) with ESMTPSA id 0ABA128F89B; Tue, 8 Feb 2011 12:38:28 -0600 (CST) Message-ID: <4D518D82.4090102@rice.edu> Date: Tue, 08 Feb 2011 12:37:54 -0600 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Feb 2011 19:07:43 +0000 Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, Ivan Voras 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 18:57:04 -0000 On 2/8/2011 12:27 PM, Robert Watson wrote: > > On Tue, 8 Feb 2011, Alan Cox wrote: > >> On Tue, Feb 8, 2011 at 6:20 AM, Ivan Voras 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". I would certainly have found this useful on a few occasions, and would gladly help out with implementing it. For example, it would help us in understanding the kmem_map fragmentation caused by ZFS. That said, I'm not sure how you will represent the case where UMA allocates physical memory directly and uses the direct map to access it. Alan