From owner-freebsd-arch@FreeBSD.ORG Wed Dec 22 14:08:16 2004 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10EC616A4CE; Wed, 22 Dec 2004 14:08:16 +0000 (GMT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id A2F6B43D31; Wed, 22 Dec 2004 14:08:15 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.1/8.13.1) with ESMTP id iBME8EkV001813 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Dec 2004 09:08:15 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id iBME89IQ070639; Wed, 22 Dec 2004 09:08:09 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16841.32713.807248.102959@grasshopper.cs.duke.edu> Date: Wed, 22 Dec 2004 09:08:09 -0500 (EST) To: Jun Su In-Reply-To: References: <16835.1939.301128.802993@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: alc@freebsd.org cc: arch@freebsd.org cc: tegge@freebsd.org cc: delphij@freebsd.org Subject: Re: Propose for Several Dump types X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Dec 2004 14:08:16 -0000 Jun Su writes: > On Fri, 17 Dec 2004 11:21:39 -0500 (EST), Andrew Gallatin > > To me, it seems like the most obvious way to do this would be walking > > the kernel's vm maps. But that does not work on 64-bit platforms which > > have a direct 1-1 physical/virtual address mapping. So how do you > > quickly distinguish kernel memory from user memory in the dump > > routine? I'm probably missing something simple.. > My current draft idea is to traverse the vm_map structure. Then I can > find out the vm_object list. Then dump those memory regions. I don't > understand VM much. In this area, I need input from our VM guru... Yes, we definately need the input of a VM guru.. FWIW, its my understanding that UMA does these small allocations without an object. Eg: m = vm_page_alloc(NULL, colour++, pflags | VM_ALLOC_NOOBJ); So I'm not sure how you find them. There must be some state someplace, though. Drew