From owner-freebsd-current@FreeBSD.ORG Wed Nov 3 18:30:42 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 30922106564A; Wed, 3 Nov 2010 18:30:42 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 4A39B8FC22; Wed, 3 Nov 2010 18:30:40 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id UAA12639; Wed, 03 Nov 2010 20:30:29 +0200 (EET) (envelope-from avg@freebsd.org) Message-ID: <4CD1AA45.7000504@freebsd.org> Date: Wed, 03 Nov 2010 20:30:29 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.11) Gecko/20101021 Lightning/1.0b2 Thunderbird/3.1.5 MIME-Version: 1.0 To: Alan Cox References: <4CA0DA49.2090006@freebsd.org> <4CA3A48A.5070300@freebsd.org> <4CA3BD1E.5070807@rice.edu> <4CA5911E.3000101@freebsd.org> <4CAE0060.7050607@freebsd.org> <4CAECC4D.90707@rice.edu> In-Reply-To: <4CAECC4D.90707@rice.edu> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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, 03 Nov 2010 18:30:42 -0000 on 08/10/2010 10:46 Alan Cox said the following: > Andriy Gapon wrote: >> Here's an updated patch: >> http://people.freebsd.org/~avg/amd64-minidump.3.diff > > The kernel part of the patch looks good. That said, I have one suggestion. The > current generation of AMD and Intel processors has support for 1GB pages. If you > want to make sure that this change will last us a long time, I would suggest > translating the old trick of generating a fake page table page for 2MB pages into > generating a fake page directory page for 1GB pages, rather than disposing of this > code. Let me double-check if I understand your suggestion correctly. So, if a 1GB page is used, then there will be a PDP entry for it with PS bit set, and PD entries for the range covered by the page will not be correctly set up? That is, I assumed that even if 1GB pages are used, then the corresponding PD entries are still correctly set up. But you say that this may not be the case in reality? So, I have to check PDP entry first and only if it's valid and it doesn't point to a 1GB page then I should examine corresponding PD entries. Correct? P.S. is there a macro for extracting frame address from PDPE? -- Andriy Gapon