From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1765869AbYEHS7h (ORCPT ); Thu, 8 May 2008 14:59:37 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753839AbYEHS72 (ORCPT ); Thu, 8 May 2008 14:59:28 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:57579 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751802AbYEHS70 (ORCPT ); Thu, 8 May 2008 14:59:26 -0400 Date: Thu, 8 May 2008 19:58:47 +0100 (BST) From: Hugh Dickins X-X-Sender: hugh@blonde.site To: Dave Hansen cc: Nishanth Aravamudan , Hans Rosenfeld , Ingo Molnar , Jeff Chua , Thomas Gleixner , "H. Peter Anvin" , Gabriel C , Arjan van de Ven , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] x86: fix PAE pmd_bad bootup warning In-Reply-To: <1210272164.7905.66.camel@nimitz.home.sr71.net> Message-ID: References: <20080506202201.GB12654@escobedo.amd.com> <1210106579.4747.51.camel@nimitz.home.sr71.net> <20080508143453.GE12654@escobedo.amd.com> <1210258350.7905.45.camel@nimitz.home.sr71.net> <20080508151145.GG12654@escobedo.amd.com> <1210261882.7905.49.camel@nimitz.home.sr71.net> <20080508161925.GH12654@escobedo.amd.com> <20080508163352.GN23990@us.ibm.com> <20080508165111.GI12654@escobedo.amd.com> <20080508171657.GO23990@us.ibm.com> <1210272164.7905.66.camel@nimitz.home.sr71.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 8 May 2008, Dave Hansen wrote: > > But, I do think it is absolutely insane to have pmd_clear_bad() going > after perfectly good hugetlb pmds. The way it is set up now, people are > bound to miss the hugetlb pages because just about every single > pagetable walk has to be specially coded to handle or avoid them. We > obviously missed it, here, and we had two good examples in the same > file! :) Like it or not, the pgd/pud/pmd/pte hierarchy cannot be assumed once you're amongst hugepages. What happens varies from architecture to architecture. Perhaps the hugepage specialists could look at what in fact the different architectures we know today are doing, and come up with a better abstraction to encompass them all. But it's simply wrong for a "generic" pagewalker to be going blindly in there. Two good examples in the same file?? Hugh