From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754219AbbGXXJJ (ORCPT ); Fri, 24 Jul 2015 19:09:09 -0400 Received: from mail-pd0-f182.google.com ([209.85.192.182]:32951 "EHLO mail-pd0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753516AbbGXXJH (ORCPT ); Fri, 24 Jul 2015 19:09:07 -0400 Date: Fri, 24 Jul 2015 16:09:05 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Vlastimil Babka cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mel Gorman , Greg Thelen , "Aneesh Kumar K.V" , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Naoya Horiguchi Subject: Re: [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE In-Reply-To: <55B2A596.1010101@suse.cz> Message-ID: References: <1437749126-25867-1-git-send-email-vbabka@suse.cz> <55B2A596.1010101@suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) 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 Fri, 24 Jul 2015, Vlastimil Babka wrote: > > I assume you looked at the collapse_huge_page() case and decided that it > > needs no modification since the gfp mask is used later for other calls? > > Yeah. Not that the memcg charge parts would seem to care about __GFP_THISNODE, > though. > Hmm, not sure that memcg would ever care about __GFP_THISNODE. I wonder if it make more sense to remove setting __GFP_THISNODE in collapse_huge_page()? khugepaged_alloc_page() seems fine with the new alloc_pages_exact_node() semantics. > >> diff --git a/mm/migrate.c b/mm/migrate.c > >> index f53838f..d139222 100644 > >> --- a/mm/migrate.c > >> +++ b/mm/migrate.c > >> @@ -1554,10 +1554,8 @@ static struct page *alloc_misplaced_dst_page(struct page *page, > >> struct page *newpage; > >> > >> newpage = alloc_pages_exact_node(nid, > >> - (GFP_HIGHUSER_MOVABLE | > >> - __GFP_THISNODE | __GFP_NOMEMALLOC | > >> - __GFP_NORETRY | __GFP_NOWARN) & > >> - ~GFP_IOFS, 0); > >> + (GFP_HIGHUSER_MOVABLE | __GFP_NOMEMALLOC | > >> + __GFP_NORETRY | __GFP_NOWARN) & ~GFP_IOFS, 0); > >> > >> return newpage; > >> } > > [snip] > > > > What about the alloc_pages_exact_node() in new_page_node()? > > Oops, seems I missed that one. So the API seems ok otherwise? > Yup! And I believe that this patch doesn't cause any regression after the new_page_node() issue is fixed. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pd0-f180.google.com (mail-pd0-f180.google.com [209.85.192.180]) by kanga.kvack.org (Postfix) with ESMTP id 0949F6B0038 for ; Fri, 24 Jul 2015 19:09:08 -0400 (EDT) Received: by pdjr16 with SMTP id r16so20195486pdj.3 for ; Fri, 24 Jul 2015 16:09:07 -0700 (PDT) Received: from mail-pd0-x22d.google.com (mail-pd0-x22d.google.com. [2607:f8b0:400e:c02::22d]) by mx.google.com with ESMTPS id os6si23964374pab.195.2015.07.24.16.09.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2015 16:09:07 -0700 (PDT) Received: by pdrg1 with SMTP id g1so20013425pdr.2 for ; Fri, 24 Jul 2015 16:09:06 -0700 (PDT) Date: Fri, 24 Jul 2015 16:09:05 -0700 (PDT) From: David Rientjes Subject: Re: [RFC v2 1/4] mm: make alloc_pages_exact_node pass __GFP_THISNODE In-Reply-To: <55B2A596.1010101@suse.cz> Message-ID: References: <1437749126-25867-1-git-send-email-vbabka@suse.cz> <55B2A596.1010101@suse.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Mel Gorman , Greg Thelen , "Aneesh Kumar K.V" , Christoph Lameter , Pekka Enberg , Joonsoo Kim , Naoya Horiguchi On Fri, 24 Jul 2015, Vlastimil Babka wrote: > > I assume you looked at the collapse_huge_page() case and decided that it > > needs no modification since the gfp mask is used later for other calls? > > Yeah. Not that the memcg charge parts would seem to care about __GFP_THISNODE, > though. > Hmm, not sure that memcg would ever care about __GFP_THISNODE. I wonder if it make more sense to remove setting __GFP_THISNODE in collapse_huge_page()? khugepaged_alloc_page() seems fine with the new alloc_pages_exact_node() semantics. > >> diff --git a/mm/migrate.c b/mm/migrate.c > >> index f53838f..d139222 100644 > >> --- a/mm/migrate.c > >> +++ b/mm/migrate.c > >> @@ -1554,10 +1554,8 @@ static struct page *alloc_misplaced_dst_page(struct page *page, > >> struct page *newpage; > >> > >> newpage = alloc_pages_exact_node(nid, > >> - (GFP_HIGHUSER_MOVABLE | > >> - __GFP_THISNODE | __GFP_NOMEMALLOC | > >> - __GFP_NORETRY | __GFP_NOWARN) & > >> - ~GFP_IOFS, 0); > >> + (GFP_HIGHUSER_MOVABLE | __GFP_NOMEMALLOC | > >> + __GFP_NORETRY | __GFP_NOWARN) & ~GFP_IOFS, 0); > >> > >> return newpage; > >> } > > [snip] > > > > What about the alloc_pages_exact_node() in new_page_node()? > > Oops, seems I missed that one. So the API seems ok otherwise? > Yup! And I believe that this patch doesn't cause any regression after the new_page_node() issue is fixed. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org