[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180211154746.j33vipgepv75dw3r@node.shutemov.name>
Date: Sun, 11 Feb 2018 18:47:46 +0300
From: "Kirill A. Shutemov" <kirill@...temov.name>
To: Konstantin Khlebnikov <koct9i@...il.com>
Cc: Konstantin Khlebnikov <khlebnikov@...dex-team.ru>,
linux-mm@...ck.org, Andrew Morton <akpm@...ux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Michal Hocko <mhocko@...e.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Nicholas Piggin <npiggin@...il.com>
Subject: Re: [PATCH v2] mm/huge_memory.c: reorder operations in
__split_huge_page_tail()
On Sun, Feb 11, 2018 at 06:32:10PM +0300, Konstantin Khlebnikov wrote:
> On Sun, Feb 11, 2018 at 6:14 PM, Kirill A. Shutemov
> <kirill@...temov.name> wrote:
> > On Sun, Feb 11, 2018 at 05:29:37PM +0300, Konstantin Khlebnikov wrote:
> >> And replace page_ref_inc()/page_ref_add() with page_ref_unfreeze() which
> >> is made especially for that and has semantic of smp_store_release().
> >
> > Nak on this part.
> >
> > page_ref_unfreeze() uses atomic_set() which neglects the situation in the
> > comment you're removing.
>
> Why? look into x86 smp_store_release
> for PPro it use same sequence smp_wb + WRITE_ONCE
> As I see spin_unlock uses exactly this macro.
>
> Anyway if page_ref_unfreeze cannot handle races with
> get_page_unless_zero() then it completely useless,
Okay, fair enough.
But please call it out it the commit message.
--
Kirill A. Shutemov
Powered by blists - more mailing lists