[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a9518500-cc2a-ce15-76a4-73a31b744852@oracle.com>
Date: Tue, 6 Feb 2018 13:18:53 -0500
From: Daniel Jordan <daniel.m.jordan@...cle.com>
To: Laurent Dufour <ldufour@...ux.vnet.ibm.com>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Cc: aaron.lu@...el.com, ak@...ux.intel.com, akpm@...ux-foundation.org,
Dave.Dice@...cle.com, dave@...olabs.net,
khandual@...ux.vnet.ibm.com, mgorman@...e.de, mhocko@...nel.org,
pasha.tatashin@...cle.com, steven.sistare@...cle.com,
yossi.lev@...cle.com
Subject: Re: [RFC PATCH v1 13/13] mm: splice local lists onto the front of the
LRU
On 02/02/2018 10:22 AM, Laurent Dufour wrote:
> On 01/02/2018 00:04, daniel.m.jordan@...cle.com wrote:
...snip...
>> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
>> index 99a54df760e3..6911626f29b2 100644
>> --- a/mm/memcontrol.c
>> +++ b/mm/memcontrol.c
>> @@ -2077,6 +2077,7 @@ static void lock_page_lru(struct page *page, int *isolated)
>>
>> lruvec = mem_cgroup_page_lruvec(page, zone->zone_pgdat);
>> ClearPageLRU(page);
>> + smp_rmb(); /* Pairs with smp_wmb in __pagevec_lru_add */
>
> Why not include the call to smp_rmb() in del_page_from_lru_list() instead
> of spreading smp_rmb() before calls to del_page_from_lru_list() ?
Yes, this is what I should have done. The memory barriers came from
another patch I squashed in and I didn't look back to see how obvious
the encapsulation was.
Powered by blists - more mailing lists