[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d0032404-e627-2d51-9c7b-42f5cdf29929@infradead.org>
Date: Thu, 23 Mar 2023 21:30:14 -0700
From: Randy Dunlap <rdunlap@...radead.org>
To: Feng Tang <feng.tang@...el.com>
Cc: Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org,
linux-kernel@...r.kernel.org,
Arnaldo Carvalho de Melo <acme@...hat.com>,
Joe Mario <jmario@...hat.com>, Ingo Molnar <mingo@...hat.com>,
Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Eric Dumazet <edumazet@...gle.com>,
Shakeel Butt <shakeelb@...gle.com>, dave.hansen@...el.com,
ying.huang@...el.com, tim.c.chen@...el.com, andi.kleen@...el.com
Subject: Re: [PATCH RFC] Documentation: Add document for false sharing
Hi--
On 3/23/23 20:03, Feng Tang wrote:
> Hi Randy,
>
> Thank you for the thorough reviews!
>
> On Thu, Mar 23, 2023 at 09:49:02AM -0700, Randy Dunlap wrote:
>> Hi,
>>
>> Lots of good/interesting info here.
>>
>> On 3/23/23 01:26, Feng Tang wrote:
>>> From: "Tang, Feng" <feng.tang@...el.com>
>>> +
>>> +'refcount' is modified frequently, but 'name' is set once at object
>>> +creation time and is never modified. When many CPUs access 'foo' at
>>> +the same time, and 'refcount' is only bumped by one CPU frequently,
>>> +while 'name' is read by all other CPUs, which have to reload the whole
>>> +cache line over and over, even though the 'name' is never changed.
>>
>> That last "sentence" is not a sentence.
>
> How about:
>
> "
> When many CPUs access 'foo' at the same time, with 'refcount' being only
> bumped by one CPU frequently and 'name' being read by other CPUs, all
> those reading CPUs have to reload the whole cache line over and over
> due to the 'sharing', even though 'name' is never changed.
> "
> ?
Yes, that's good. Thanks.
--
~Randy
Powered by blists - more mailing lists