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=-2.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 B4D4FC433E0 for ; Thu, 11 Mar 2021 01:05:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 1408A64FC1 for ; Thu, 11 Mar 2021 01:05:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1408A64FC1 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 397778D025C; Wed, 10 Mar 2021 20:05:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 347578D0250; Wed, 10 Mar 2021 20:05:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E8E38D025C; Wed, 10 Mar 2021 20:05:25 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0031.hostedemail.com [216.40.44.31]) by kanga.kvack.org (Postfix) with ESMTP id 0220D8D0250 for ; Wed, 10 Mar 2021 20:05:24 -0500 (EST) Received: from smtpin26.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id B6E995828 for ; Thu, 11 Mar 2021 01:05:24 +0000 (UTC) X-FDA: 77905800168.26.0E0760E Received: from mail-il1-f177.google.com (mail-il1-f177.google.com [209.85.166.177]) by imf13.hostedemail.com (Postfix) with ESMTP id 50691E00011A for ; Thu, 11 Mar 2021 01:05:22 +0000 (UTC) Received: by mail-il1-f177.google.com with SMTP id p10so17416648ils.9 for ; Wed, 10 Mar 2021 17:05:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=tzLcpbEHlICK/TY3veXTxXrzL8MkHekFvgC0dEJ6xUY=; b=LZBOFnzlnL8BCHZYy2gxCniNTx8DL20WUALibFUmm2iub0s76sHOMehyxztAiu90NF bo5viCGgzdHJFUlaV3nPaCd9YSTdXCl94XRILUQT4MbA9Hg1i2gFq7hjyk3TSkQXe5o0 0j+3IS/hp3G0YuU8WDvDjXyGSG5rL8sh1Ll4D6GtDa5UL/4ZPHcdbQl8VKPI8oP3SqNH NrIHlUMxzQKnjdH8POjHlTibZIMzz2EVlXcyhF6eKyqyuHl89tIZVkX46OnkDtBurmKa 6csBLXxCefF/9gYoCVFAsFDH2vd1+s3LXFi8gfDyse3VUc0JkBMLqUHIG9oh+LIzcoNt DA4Q== 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=tzLcpbEHlICK/TY3veXTxXrzL8MkHekFvgC0dEJ6xUY=; b=sSHLSfLI4fmSl2MXilk2UYs8ISvTbG/B85Xq53ctQvA70yPlP1JLKI6by0JCFmHbji Ri1Z8TGWF58BQk963U7v1zuntrWePeLu6QrXwzPBKjpXwbJyPd1BbINZjAJBjU0B/vlc dq31hH2tZnK38EBvrqyfbUKAZhmUEac/IstOrgTnsXKJqor+DtprA9sL6jWOxbuxyA8Q Kwf6I/NqEKQ0NqrDvTzGVz3G4B6b00zlwrPkXWGyfYcj2kNOfHWo25z51MsAO7QWJYJV jgJGsxA13yfxn0YqL5VBN+YUVYIoYrgfah62tomEINU+eKBD4Zman63JJS894l6g0aqT PdCA== X-Gm-Message-State: AOAM531kkfHn7BizjsykbZ9yA6ztV6aanYFBt1XGLJtxxSFFcMN4iYvB DOdWcBx/e47LQp5m1AY7rrj4p9Dd1u1SX2MTNbI= X-Google-Smtp-Source: ABdhPJygjZiXjz3N6qVWwrLUn617NgpkFbTB7aeFU0n7/FT/9HvsgsOtss8INOhAOhrg8Bm9D/+acdHqQLrNKB/mbmE= X-Received: by 2002:a92:c04b:: with SMTP id o11mr4720645ilf.42.1615424723613; Wed, 10 Mar 2021 17:05:23 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alexander Duyck Date: Wed, 10 Mar 2021 17:05:12 -0800 Message-ID: Subject: Re: [PATCH v17 1/9] mm: Adjust shuffle code to allow for future coalescing To: "Bodeddula, Balasubramaniam" Cc: "aarcange@redhat.com" , "akpm@linux-foundation.org" , "alexander.h.duyck@linux.intel.com" , "dan.j.williams@intel.com" , "dave.hansen@intel.com" , "david@redhat.com" , "konrad.wilk@oracle.com" , "kvm@vger.kernel.org" , "lcapitulino@redhat.com" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , "mgorman@techsingularity.net" , "mhocko@kernel.org" , "mst@redhat.com" , "nitesh@redhat.com" , "osalvador@suse.de" , "pagupta@redhat.com" , "pbonzini@redhat.com" , "riel@surriel.com" , "vbabka@suse.cz" , "wei.w.wang@intel.com" , "willy@infradead.org" , "yang.zhang.wz@gmail.com" , "Graf (AWS), Alexander" , "Herrenschmidt, Benjamin" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: gwmkigc7spkp9tq78wiswhiq5w13c8ke X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 50691E00011A Received-SPF: none (gmail.com>: No applicable sender policy available) receiver=imf13; identity=mailfrom; envelope-from=""; helo=mail-il1-f177.google.com; client-ip=209.85.166.177 X-HE-DKIM-Result: pass/pass X-HE-Tag: 1615424722-800168 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: Hi Bala, There was a similar effort several months ago that was trying to do this in conjunction with pre-zeroing of pages. I suspect if you wanted to you could probably pick up some of their patch set and work with that. It can be found at: https://www.spinics.net/lists/linux-mm/msg239735.html Thanks. - Alex On Tue, Mar 9, 2021 at 12:13 AM Bodeddula, Balasubramaniam wrote: > > Hi Alexander, > > > > My team was evaluating FPR and observed that these patches don=E2=80=99t = report memory for deallocated hugeapages directly and need to cycle through= buddy allocator. For example, say we need to allocate a maximum of 12 * 1G= hugepages (by setting nr_hugepages), use 8 * 1G hugepages, and then deallo= cate 4 * 1G hugepages. Unlike regular 4K pages, this 4G worth of memory wil= l not be reported until we set nr_hugepages to 8 (wait sometime(?) for FPR = to do its work) and set it back again to 12. While this works fine in theor= y, in practice, setting nr_hugepages to 12 could fail too due to fragmenta= tion (this could depend on other processes memory usage behavior). > > > > If FPR could report this free memory without cycling through buddy alloca= tor, it makes the solution more robust. I am looking for advice on how feas= ible this approach is and what would be the effort for building this functi= onality. In general, if there are other thoughts on how we can address this= , please do let me know. > > > > Thanks, > > bala