mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Michal Hocko <mhocko@suse.com>
To: Muchun Song <songmuchun@bytedance.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>,
	Andi Kleen <ak@linux.intel.com>,
	Linux Memory Management List <linux-mm@kvack.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: [External] Re: [PATCH v2 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page
Date: Thu, 7 Jan 2021 12:22:19 +0100	[thread overview]
Message-ID: <20210107112219.GH13207@dhcp22.suse.cz> (raw)
In-Reply-To: <CAMZfGtWwHOVCvFUvm-r74k1GEEujW_HniLFOMKbykny7Cu09eA@mail.gmail.com>

On Thu 07-01-21 17:01:16, Muchun Song wrote:
> On Thu, Jan 7, 2021 at 4:39 PM Michal Hocko <mhocko@suse.com> wrote:
> >
> > On Thu 07-01-21 11:11:41, Muchun Song wrote:
> > > On Thu, Jan 7, 2021 at 1:07 AM Michal Hocko <mhocko@suse.com> wrote:
> > > >
> > > > On Wed 06-01-21 16:47:37, Muchun Song wrote:
> > > > > When dissolve_free_huge_page() races with __free_huge_page(), we can
> > > > > do a retry. Because the race window is small.
> > > >
> > > > Is this a bug fix or mere optimization. I have hard time to tell from
> > > > the description.
> > >
> > > It is optimization. Thanks.
> > >
> > > >
> > > > > Signed-off-by: Muchun Song <songmuchun@bytedance.com>
> > > > > ---
> > > > >  mm/hugetlb.c | 26 +++++++++++++++++++++-----
> > > > >  1 file changed, 21 insertions(+), 5 deletions(-)
> > > > >
> > > > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> > > > [...]
> > > > > @@ -1825,6 +1828,14 @@ int dissolve_free_huge_page(struct page *page)
> > > > >       }
> > > > >  out:
> > > > >       spin_unlock(&hugetlb_lock);
> > > > > +
> > > > > +     /*
> > > > > +      * If the freeing of the HugeTLB page is put on a work queue, we should
> > > > > +      * flush the work before retrying.
> > > > > +      */
> > > > > +     if (unlikely(rc == -EAGAIN))
> > > > > +             flush_work(&free_hpage_work);
> > > >
> > > > Is it safe to wait for the work to finish from this context?
> > >
> > > Yes. It is safe.
> >
> > Please expand on why in the changelog. Same for the optimization
> > including some numbers showing it really helps.
> 
> OK. Changelog should be updated. Do you agree the race window
> is quite small?

Yes, the race is very rare and the window itself should be relatively
small. This doesn't really answer the question about blocking though.

> If so, why is it not an optimization? Don’t we dissolve
> the page as successfully as possible when we call
> dissolve_free_huge_page()? I am confused about numbers showing.
> Because this is not a performance optimization, but an increase in
> the success rate of dissolving.

And it is a very theoretical one, right? Can you even trigger it? What
would happen if the race is lost? Is it serious? This all would be part
of the changelog ideally. This is a tricky area that spans hugetlb,
memory hotplug and hwpoisoning. All of them tricky. 
-- 
Michal Hocko
SUSE Labs

  reply	other threads:[~2021-01-07 11:23 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-06  8:47 [PATCH v2 0/6] Fix some bugs about HugeTLB code Muchun Song
2021-01-06  8:47 ` [PATCH v2 1/6] mm: migrate: do not migrate HugeTLB page whose refcount is one Muchun Song
2021-01-06 16:13   ` Michal Hocko
2021-01-07  2:52     ` [External] " Muchun Song
2021-01-07 11:16       ` Michal Hocko
2021-01-07 11:24         ` Muchun Song
2021-01-07 11:48           ` Michal Hocko
2021-01-06  8:47 ` [PATCH v2 2/6] mm: hugetlbfs: fix cannot migrate the fallocated HugeTLB page Muchun Song
2021-01-06 16:35   ` Michal Hocko
2021-01-06 19:30     ` Mike Kravetz
2021-01-06 20:02       ` Michal Hocko
2021-01-06 21:07         ` Mike Kravetz
2021-01-07  8:36           ` Michal Hocko
2021-01-07  2:58     ` [External] " Muchun Song
2021-01-06  8:47 ` [PATCH v2 3/6] mm: hugetlb: fix a race between freeing and dissolving the page Muchun Song
2021-01-06 16:56   ` Michal Hocko
2021-01-06 20:58     ` Mike Kravetz
2021-01-07  3:08       ` [External] " Muchun Song
2021-01-07  8:40       ` Michal Hocko
2021-01-08  0:52         ` Mike Kravetz
2021-01-08  8:28           ` Michal Hocko
2021-01-07  5:39     ` [External] " Muchun Song
2021-01-07  8:41       ` Michal Hocko
2021-01-07  8:53         ` Muchun Song
2021-01-07 11:18           ` Michal Hocko
2021-01-07 11:38             ` Muchun Song
2021-01-07 12:38               ` Michal Hocko
2021-01-07 12:59                 ` Muchun Song
2021-01-07 14:11                   ` Michal Hocko
2021-01-07 15:11                     ` Muchun Song
2021-01-08  1:06                       ` Mike Kravetz
2021-01-08  2:38                         ` Muchun Song
2021-01-08  8:43                       ` Michal Hocko
2021-01-08  9:01                         ` Muchun Song
2021-01-08  9:31                           ` Michal Hocko
2021-01-08 10:08                             ` Muchun Song
2021-01-08 11:44                               ` Michal Hocko
2021-01-08 11:52                                 ` Muchun Song
2021-01-08 12:04                                   ` Michal Hocko
2021-01-08 12:24                                     ` Muchun Song
2021-01-06  8:47 ` [PATCH v2 4/6] mm: hugetlb: add return -EAGAIN for dissolve_free_huge_page Muchun Song
2021-01-06 17:07   ` Michal Hocko
2021-01-07  3:11     ` [External] " Muchun Song
2021-01-07  8:39       ` Michal Hocko
2021-01-07  9:01         ` Muchun Song
2021-01-07 11:22           ` Michal Hocko [this message]
2021-01-06  8:47 ` [PATCH v2 5/6] mm: hugetlb: fix a race between isolating and freeing page Muchun Song
2021-01-06 17:10   ` Michal Hocko
2021-01-06  8:47 ` [PATCH v2 6/6] mm: hugetlb: remove VM_BUG_ON_PAGE from page_huge_active Muchun Song
2021-01-06 17:16   ` Michal Hocko
2021-01-08 22:24   ` Mike Kravetz
2021-01-09  4:07     ` [External] " Muchun Song
2021-01-07  9:30 ` [PATCH v2 0/6] Fix some bugs about HugeTLB code David Hildenbrand
2021-01-07  9:40   ` [External] " Muchun Song
2021-01-07 10:10     ` David Hildenbrand
2021-01-07 10:16       ` Muchun Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210107112219.GH13207@dhcp22.suse.cz \
    --to=mhocko@suse.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mike.kravetz@oracle.com \
    --cc=n-horiguchi@ah.jp.nec.com \
    --cc=songmuchun@bytedance.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®