From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 22:27:00 2010 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7445D106566B; Wed, 29 Sep 2010 22:27:00 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh6.mail.rice.edu (mh6.mail.rice.edu [128.42.201.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3FBB68FC08; Wed, 29 Sep 2010 22:27:00 +0000 (UTC) Received: from mh6.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh6.mail.rice.edu (Postfix) with ESMTP id 6F08E28F7C0; Wed, 29 Sep 2010 17:26:59 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh6.mail.rice.edu, auth channel Received: from mh6.mail.rice.edu ([127.0.0.1]) by mh6.mail.rice.edu (mh6.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 0-VMDs98Spp3; Wed, 29 Sep 2010 17:26:59 -0500 (CDT) Received: from [10.209.194.120] (unknown [10.209.194.120]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh6.mail.rice.edu (Postfix) with ESMTPSA id 2BC5028F797; Wed, 29 Sep 2010 17:26:59 -0500 (CDT) Message-ID: <4CA3BD1E.5070807@rice.edu> Date: Wed, 29 Sep 2010 17:26:38 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: Andriy Gapon References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> In-Reply-To: <4CA3A48A.5070300@freebsd.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Wed, 29 Sep 2010 22:38:25 +0000 Cc: Alan Cox , freebsd-current@freebsd.org Subject: Re: minidump size on amd64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2010 22:27:00 -0000 On 9/29/2010 3:41 PM, Andriy Gapon wrote: > on 27/09/2010 20:54 Andriy Gapon said the following: >> It seems that minidump on amd64 is always dumping at least about 1GB of data >> regardless of actual memory size and usage and thus can be even larger than >> regular dump. >> >> Specifically, I suspect the following code: >> for (va = VM_MIN_KERNEL_ADDRESS; va< MAX(KERNBASE + NKPT * NBPDR, >> kernel_vm_end); va += NBPDR) { >> i = (va>> PDPSHIFT)& ((1ul<< NPDPEPGSHIFT) - 1); >> /* >> * We always write a page, even if it is zero. Each >> * page written corresponds to 2MB of space >> */ >> ptesize += PAGE_SIZE; >> >> It seems that difference between KERNBASE and VM_MIN_KERNEL_ADDRESS is already >> ~500G. Which means 500G divided by 2M equals 250K iterations/pages. Which is 1GB >> of data. >> >> Looks like this came from amd64 KVA expansion. >> And it seems a little bit wasteful? > So perhaps we need to add another level of indirection? > I.e. first dump contiguous array of "pseudo-pde" entries that would point to > chunks of "pseudo-pte" entries, so that "pseudo-pte" entries could be sparse. > This is instead of dumping 1GB of contiguous "pseudo-ptes" as we do now. > That would be the best approach. That said, for the foreseeable future, the kernel page table on amd64 will have two valid ranges, no more, no less. So, if it's much easier to modify minidump to deal with a page table that is assumed to have two contiguous parts, just do it. That assumption should remain valid for a few years. Alan