From patchwork Tue Apr 19 18:35:06 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Christoph Lameter (Ampere)" X-Patchwork-Id: 718691 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.3) with ESMTP id p3JIZCdd030962 for ; Tue, 19 Apr 2011 18:35:12 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753933Ab1DSSfL (ORCPT ); Tue, 19 Apr 2011 14:35:11 -0400 Received: from smtp109.prem.mail.ac4.yahoo.com ([76.13.13.92]:40302 "HELO smtp109.prem.mail.ac4.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1752663Ab1DSSfK (ORCPT ); Tue, 19 Apr 2011 14:35:10 -0400 Received: (qmail 990 invoked from network); 19 Apr 2011 18:35:09 -0000 Received: from router.home (cl@99.30.10.212 with plain) by smtp109.prem.mail.ac4.yahoo.com with SMTP; 19 Apr 2011 11:35:09 -0700 PDT X-Yahoo-SMTP: _Dag8S.swBC1p4FJKLCXbs8NQzyse1SYSgnAbY0- X-YMail-OSG: Dcpx3YEVM1keBj99gb7ds8mL27WxlYw5m8sqx5SJa0suAdr JHZUbabeMkeyYla6UagcnRMggDy5XtkH5dzRmGqESTfBoDmm6cge1JbRcAwK W_pO6VNr98ubQNBqcs9VJXsli.w23uzg_l7ovp9AVYj6YkdqopbsDrMmJGja VgRMqoWPFTV0z5t4TAzXuqXWrWtzdVH3Z3pVfyFs3o7HIuJNJBdnIxY7.umd .F4Ys5qcSxp5HrbcIDdnCO7TX40lnrEp2iRpAgBXaxwKQEfNlHQDFq0sRSO3 rL1msys5yRbzF43SFulkCBV_i1Jvv5qiWpuw97f46y3syGR.FrEHLwsEsFCn O2zMegZ6mJun1pCSVgB4zam2W X-Yahoo-Newman-Property: ymail-3 Received: from cl (helo=localhost) by router.home with local-esmtp (Exim 4.71) (envelope-from ) id 1QCFlU-0005P9-DC; Tue, 19 Apr 2011 13:35:08 -0500 Date: Tue, 19 Apr 2011 13:35:06 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@router.home To: James Bottomley cc: Pekka Enberg , Michal Hocko , Andrew Morton , Hugh Dickins , linux-mm@kvack.org, LKML , linux-parisc@vger.kernel.org, David Rientjes Subject: Re: [PATCH v3] mm: make expand_downwards symmetrical to expand_upwards In-Reply-To: <1303237217.3171.39.camel@mulgrave.site> Message-ID: References: <20110415135144.GE8828@tiehlicka.suse.cz> <20110418100131.GD8925@tiehlicka.suse.cz> <20110418135637.5baac204.akpm@linux-foundation.org> <20110419111004.GE21689@tiehlicka.suse.cz> <1303228009.3171.18.camel@mulgrave.site> <1303233088.3171.26.camel@mulgrave.site> <1303235306.3171.33.camel@mulgrave.site> <1303237217.3171.39.camel@mulgrave.site> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Sender: linux-parisc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-parisc@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Tue, 19 Apr 2011 18:35:12 +0000 (UTC) On Tue, 19 Apr 2011, James Bottomley wrote: > > } > > > > How in the world did you get a zone setup in node 1 with a !NUMA config? > > I told you ... I forced an allocation into the first discontiguous > region. That will return 1 for page_to_nid(). How? The kernel has no concept of a node 1 without CONFIG_NUMA and so you cannot tell the page allocator to allocate from node 1. zone_to_nid is used as a fallback mechanism for page_to_nid() and as shown will always return 0 for !NUMA configs. page_to_nid(x) == zone_to_nid(page_zone(x)) must hold true. It is not here. > > The problem seems to be that the kernel seems to allow a > > definition of a page_to_nid() function that returns non zero in the !NUMA > > case. > > This is called reality, yes. There you have the bug. Fix that and things will work fine. > right, that's what I told you: slub is broken because it's making a > wrong assumption. Look in asm-generic/memory_model.h it shows how the > page_to_nid() is used in finding the pfn array. DISCONTIGMEM uses some > of the numa properties (including assigning zones to the discontiguous > regions). Bitrotted code? If it uses numa properties then it must use a zone field in struct zone. So DISCONTIGMEM seems to require CONFIG_NUMA. > > If you think that is broken then we have brokenness all over the kernel > > whenever we determine the node from a page and use that to do a lookup. > > Not really. The rest of the kernel uses the proper macros. in > DISCONTIGMEM but !NUMA configs, the numa macros expand correctly. > You've cut across that with all the CONFIG_NUMA checks in slub. What are "the proper macros"? AFAICT page_to_nid() is the proper way to access the node of a page. If page_to_nid() returns 1 then you have a zone that the kernel knows of as being in node 0 having a page on a different node. We can likely force page_to_nid to ignore the node information that have been erroneously placed there but this looks like something deeper is wrong here. The node field in struct page is not only used for the Linux support of a NUMA node but also for blocks of memory. Those should be separate things. --- include/linux/mm.h | 4 ++++ 1 file changed, 4 insertions(+) -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Index: linux-2.6/include/linux/mm.h =================================================================== --- linux-2.6.orig/include/linux/mm.h 2011-04-19 13:20:20.092521248 -0500 +++ linux-2.6/include/linux/mm.h 2011-04-19 13:21:05.962521196 -0500 @@ -665,6 +665,7 @@ static inline int zone_to_nid(struct zon #endif } +#ifdef CONFIG_NUMA #ifdef NODE_NOT_IN_PAGE_FLAGS extern int page_to_nid(struct page *page); #else @@ -673,6 +674,9 @@ static inline int page_to_nid(struct pag return (page->flags >> NODES_PGSHIFT) & NODES_MASK; } #endif +#else +#define page_to_nid(x) 0 +#endif static inline struct zone *page_zone(struct page *page) {