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;
MIME-Version: 1.0
References: <A221FEC9-71CE-4D0A-9F39-F75C337B5D22@contoso.com>
In-Reply-To: <A221FEC9-71CE-4D0A-9F39-F75C337B5D22@contoso.com>
From:   Alexander Duyck <alexander.duyck@gmail.com>
Date:   Wed, 10 Mar 2021 17:05:12 -0800
Message-ID: <CAKgT0Ud508jLc4NVm1XxNSjEnq3NoLS=Q1V+o=6JZoJF_r_m0A@mail.gmail.com>
Subject: Re: [PATCH v17 1/9] mm: Adjust shuffle code to allow for future coalescing
To:     "Bodeddula, Balasubramaniam" <bodeddub@amazon.com>
Cc:     "aarcange@redhat.com" <aarcange@redhat.com>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "alexander.h.duyck@linux.intel.com" 
        <alexander.h.duyck@linux.intel.com>,
        "dan.j.williams@intel.com" <dan.j.williams@intel.com>,
        "dave.hansen@intel.com" <dave.hansen@intel.com>,
        "david@redhat.com" <david@redhat.com>,
        "konrad.wilk@oracle.com" <konrad.wilk@oracle.com>,
        "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
        "lcapitulino@redhat.com" <lcapitulino@redhat.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "linux-mm@kvack.org" <linux-mm@kvack.org>,
        "mgorman@techsingularity.net" <mgorman@techsingularity.net>,
        "mhocko@kernel.org" <mhocko@kernel.org>,
        "mst@redhat.com" <mst@redhat.com>,
        "nitesh@redhat.com" <nitesh@redhat.com>,
        "osalvador@suse.de" <osalvador@suse.de>,
        "pagupta@redhat.com" <pagupta@redhat.com>,
        "pbonzini@redhat.com" <pbonzini@redhat.com>,
        "riel@surriel.com" <riel@surriel.com>,
        "vbabka@suse.cz" <vbabka@suse.cz>,
        "wei.w.wang@intel.com" <wei.w.wang@intel.com>,
        "willy@infradead.org" <willy@infradead.org>,
        "yang.zhang.wz@gmail.com" <yang.zhang.wz@gmail.com>,
        "Graf (AWS), Alexander" <graf@amazon.de>,
        "Herrenschmidt, Benjamin" <benh@amazon.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

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
<bodeddub@amazon.com> 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