From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 94AB7C433E2 for ; Thu, 28 May 2020 17:39:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 79942207F5 for ; Thu, 28 May 2020 17:39:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=nitingupta.dev header.i=@nitingupta.dev header.b="AMSzGREp" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405627AbgE1RjM (ORCPT ); Thu, 28 May 2020 13:39:12 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43412 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405577AbgE1RjL (ORCPT ); Thu, 28 May 2020 13:39:11 -0400 Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C6C01C08C5C6 for ; Thu, 28 May 2020 10:39:10 -0700 (PDT) Received: by mail-lj1-x243.google.com with SMTP id c11so32304099ljn.2 for ; Thu, 28 May 2020 10:39:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nitingupta.dev; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GSyn/GzlUuBVZreRe5FoudqPDQtAy00iQYfXxKL+O/Q=; b=AMSzGREpSnoqwtwv9pZaGx8ez0dlArn60F3wpoUwlsaAoeLWH+YHNw44SgBlBc7vag nn2sp9vyKpRzVPN2on4hlPXML8hzV9g2MyHMr3GY249VZJRGGaUIZ5yc10CadFZiTtzk vcuNxha92NhynzKiT0b3k8qSRW7e8dp7oNXB84i2wREsncxeDD9rVNkm2JqJALwopBVm S+YRP+Hb5qUqPmxTTMYrYWWTXXwJKyQATZ+qjgYUdJ/8fG61hiGWvtHweD/MIWMX0a2a y8r66OlLZHSCB4BwPYW16zxiL2qM9iDqfxCMWJfACPLhLqsM2icegfAyoFt0HgTWVS4Q vlQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GSyn/GzlUuBVZreRe5FoudqPDQtAy00iQYfXxKL+O/Q=; b=dphoZE8fDn7A2hwwp1ORnno4S1B7IflvXdME63wLE5bzslapPP+7vialMJ1HLzeUg1 a24zZZCdspJTHopkrZ+AcKtHAhmrQEvS6G4ociF3eA6R+3UVz0I+9lrVYtBR31GaPC55 e4qE/z1j8fFJPHOckMAGOYmh4Ym3kRsIDBkyTiajRJZAS6t1MfzY9fyrIQUVuddsNFq9 +Ym7qGDTnwLP91wW7XrBZgsVBB2nldKGwSUjFEfaB8Mmi1qf3RCO4vAb3dZvvUiNNPnq KgOBd4hHlR4S0PL5fo3G4bqkhvlC+mMfQP7nBliyM1BwsMSugEet40kmuV+pJOheikVc Ek8w== X-Gm-Message-State: AOAM5318n0xdPRDeym/AWilJT6PKCaLvpc4ucncWFvHr1i63qsPmvue/ Ct9BHDaL1Y+Rc9lnh4lCuoOITDrmHXHWq8K+4AhmgA== X-Google-Smtp-Source: ABdhPJztXzq3yXMj4FT3uUbqkiTJL24i9SV+yD18Z6q5cM2dbT2DdkdzT9A9pFh+q0gqZ0uWQC5J3lj/V1fV3PrxgyM= X-Received: by 2002:a2e:9099:: with SMTP id l25mr2082879ljg.82.1590687549294; Thu, 28 May 2020 10:39:09 -0700 (PDT) MIME-Version: 1.0 References: <20200518181446.25759-1-nigupta@nvidia.com> <27b39956-2a21-8eef-8ebb-cb3a93a41a36@applied-asynchrony.com> In-Reply-To: From: Nitin Gupta Date: Thu, 28 May 2020 10:38:57 -0700 Message-ID: Subject: Re: [PATCH v5] mm: Proactive compaction To: Vlastimil Babka Cc: =?UTF-8?Q?Holger_Hoffst=C3=A4tte?= , Nitin Gupta , Mel Gorman , Michal Hocko , Matthew Wilcox , Andrew Morton , Mike Kravetz , Joonsoo Kim , David Rientjes , linux-kernel , linux-mm , Linux API Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, May 28, 2020 at 2:50 AM Vlastimil Babka wrote: > > On 5/28/20 11:15 AM, Holger Hoffst=C3=A4tte 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=3Dn (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 ch= oice as > long as THP's are enabled. I guess fallback to HUGETLB_PAGE_ORDER would b= e > possible if THPS are not enabled, but AFAICS some architectures don't def= ine > that. Such architectures perhaps won't benefit from proactive compaction = anyway? > I am not sure about such architectures but in such cases, we would end up calculating "fragmentation score" based on a page size which does not match the architecture's view of the "default hugepage size" which is not a terrible thing in itself as compaction can still be done in the background, after all. Since we always need a target order to calculate the fragmentation score, h= ow about this fallack scheme: HPAGE_PMD_ORDER -> HUGETLB_PAGE_ORDER -> PMD_ORDER Thanks, Nitin