Received: by 2002:a25:ef43:0:0:0:0:0 with SMTP id w3csp291170ybm; Thu, 28 May 2020 02:53:05 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwrxs3syAcONqC5YUm1KDs2UHCnJV2Y8HZIR5WXBvrKkmABCLoub0W7gql8i0/ZBzDHZY4f X-Received: by 2002:a50:f052:: with SMTP id u18mr2151801edl.16.1590659585085; Thu, 28 May 2020 02:53:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1590659585; cv=none; d=google.com; s=arc-20160816; b=jRC78SGCBSg3DwykXPR3CXe1XtXH2C0pwE2Imim7QA1OBUAyNHR+bIp8Y2MmI4LziV 9D85xF8dIqkx9+oGQV56UlJcfE2mLuO0OAZFWr30qnqbgPRLhVQDdWHMF9cWF1R0qFuP 9X1m3h/mk+S107F/0vc/44UKO1uPnrb2+V3LPWCG4Z90VYggwyveMD1wLT3GZHVWirg+ fI4sPUW9oJGjzNkPUZZG0PFI2mpujTXa0cErTGcIToJZCFT0s+FsXb44sdzxGJfePVjF ZFgEKhN9oSM96LD7DtUfyrFJ4SU+CTP92BrTvUV2aT5tCS1Pf4FZBiKLeh+0updmuB1T Wxtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=D6KHL2YWDgTF6ArxKroQXimwxlrwa6yR9+FXaUqejhM=; b=brUGSoUftYyefi77L6VCb6do7/iVozW0Ix8HsQYBIaA4U5sr5PL7Ige8Mt0g/f7uhk 2w+PFVYrsnAnks+IQQPGyGw1qxZ3Y6oi/IHj9VM8Z8xSZirMvi/F0s2tIWHk0jvnvP7q MZqz6ZIU3+QIy4PXdIhbd9zu6SufBvHYvhza5x9KbV38SZyHoQhawar8FbaR7jrTbCPF 1JnQX+08JF5wjuiPyHJUNFxe4OJwt8dTimBaObhU0DIF6bPMI+ipyq/CqPWGIpbJHgPQ uAf2l3UMse+GJLqa4RjPk+HQjNutHiVBzemPBo7o8PKAw74JgELcEpiePHf4gMCcI4eb NY/g== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o16si3244564edi.177.2020.05.28.02.52.42; Thu, 28 May 2020 02:53:05 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2387536AbgE1Jup (ORCPT + 99 others); Thu, 28 May 2020 05:50:45 -0400 Received: from mx2.suse.de ([195.135.220.15]:59470 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2387493AbgE1Juo (ORCPT ); Thu, 28 May 2020 05:50:44 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id D6AB2AD3A; Thu, 28 May 2020 09:50:41 +0000 (UTC) Subject: Re: [PATCH v5] mm: Proactive compaction To: =?UTF-8?Q?Holger_Hoffst=c3=a4tte?= , Nitin Gupta , Mel Gorman , Michal Hocko Cc: Matthew Wilcox , Andrew Morton , Mike Kravetz , Joonsoo Kim , David Rientjes , Nitin Gupta , linux-kernel , linux-mm , Linux API References: <20200518181446.25759-1-nigupta@nvidia.com> <27b39956-2a21-8eef-8ebb-cb3a93a41a36@applied-asynchrony.com> From: Vlastimil Babka Message-ID: Date: Thu, 28 May 2020 11:50:40 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: <27b39956-2a21-8eef-8ebb-cb3a93a41a36@applied-asynchrony.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/28/20 11:15 AM, Holger Hoffstätte wrote: > > On 5/18/20 8:14 PM, Nitin Gupta wrote: > [patch v5 :)] > > I've been successfully using this in my tree and it works great, but a friend > who also uses my tree just found a bug (actually an improvement ;) due to the > change from HUGETLB_PAGE_ORDER to HPAGE_PMD_ORDER in v5. > > When building with CONFIG_TRANSPARENT_HUGEPAGE=n (for some reason it was off) > HPAGE_PMD_SHIFT expands to BUILD_BUG() and compilation fails like this: Oops, I forgot about this. Still I believe HPAGE_PMD_ORDER is the best choice as long as THP's are enabled. I guess fallback to HUGETLB_PAGE_ORDER would be possible if THPS are not enabled, but AFAICS some architectures don't define that. Such architectures perhaps won't benefit from proactive compaction anyway? > ... > ./include/linux/huge_mm.h:284:28: note: in expansion of macro ‘BUILD_BUG’ > 284 | #define HPAGE_PMD_SHIFT ({ BUILD_BUG(); 0; }) > | ^~~~~~~~~ > ./include/linux/huge_mm.h:78:26: note: in expansion of macro ‘HPAGE_PMD_SHIFT’ > 78 | #define HPAGE_PMD_ORDER (HPAGE_PMD_SHIFT-PAGE_SHIFT) > | ^~~~~~~~~~~~~~~ > mm/compaction.c:1874:28: note: in expansion of macro ‘HPAGE_PMD_ORDER’ > 1874 | extfrag_for_order(zone, HPAGE_PMD_ORDER); > | ^~~~~~~~~~~~~~~ > ... > > It would be great if the whole thing would compile without THP; the only > occurrence is in fragmentation_score_zone(). Unfortunately I'm not familiar > enough with how to properly check for THP and properly calculate whatever > you're doing there, otherwise I would ifdef this away myself. ;) > > Thanks for an otherwise great patch! > > cheers, > Holger >