[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMZfGtULi=E5pNoLciaedGfNpSdopzyOzFhnzALf+nCciFRUPQ@mail.gmail.com>
Date: Thu, 7 Jan 2021 19:24:59 +0800
From: Muchun Song <songmuchun@...edance.com>
To: Michal Hocko <mhocko@...e.com>
Cc: Mike Kravetz <mike.kravetz@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Naoya Horiguchi <n-horiguchi@...jp.nec.com>,
Andi Kleen <ak@...ux.intel.com>,
Linux Memory Management List <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Yang Shi <shy828301@...il.com>
Subject: Re: [External] Re: [PATCH v2 1/6] mm: migrate: do not migrate HugeTLB
page whose refcount is one
On Thu, Jan 7, 2021 at 7:16 PM Michal Hocko <mhocko@...e.com> wrote:
>
> On Thu 07-01-21 10:52:21, Muchun Song wrote:
> > On Thu, Jan 7, 2021 at 12:13 AM Michal Hocko <mhocko@...e.com> wrote:
> > >
> > > On Wed 06-01-21 16:47:34, Muchun Song wrote:
> > > > If the refcount is one when it is migrated, it means that the page
> > > > was freed from under us. So we are done and do not need to migrate.
> > >
> > > Is this common enough that it would warrant the explicit check for each
> > > migration?
> >
> > Are you worried about the overhead caused by the check? Thanks.
>
> I am not as worried as I would like to see some actual justification for
> this optimization.
OK. The HugeTLB page can be freed after it was isolated but before
being migrated. Right? If we catch this case, it is an optimization.
I do this just like unmap_and_move() does for a base page.
> --
> Michal Hocko
> SUSE Labs
Powered by blists - more mailing lists