Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>
Newsgroups: comp.arch
Subject: Re: MSI interrupts
Date: Wed, 26 Mar 2025 13:22:04 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <vs1nlc$2h3d1$1@dont-email.me>
References: <vqto79$335c6$1@dont-email.me>
 <b1c74762d01f71cc1b8ac838dcf6d4fa@www.novabbs.org>
 <vrvukp$n29$1@reader1.panix.com> <jwv4izfncov.fsf-monnier+comp.arch@gnu.org>
 <vs14k8$1a4$1@reader1.panix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 26 Mar 2025 21:22:05 +0100 (CET)
Injection-Info: dont-email.me; posting-host="a4eec8a2f4b4f841a55717fcbf2df836";
	logging-data="2657697"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19Hs5s7T3S87bGviyU83tuei2YjkCRnxkM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:bbottEL5/vjNPpPK5M24WTgUdlY=
Content-Language: en-US
In-Reply-To: <vs14k8$1a4$1@reader1.panix.com>
Bytes: 3326

On 3/26/2025 7:57 AM, Dan Cross wrote:
> In article <jwv4izfncov.fsf-monnier+comp.arch@gnu.org>,
> Stefan Monnier  <monnier@iro.umontreal.ca> wrote:
>>> Leaving aside the unchecked boundary conditions I highlighted
>>> above, there are other questions that this raises.  You
>>> mentioned that the ESM stuff can use up to 8 cache lines in a
>>> single atomic "event"; let's count how many this code may
>>> encounter:
>>>
>>> 1. `from` may point to a cache line
>>> 2. `to` may point to a different cache line.
>>> 3. Does your architecture use a stack?  What sort of alignment
>>>     criteria do you impose?   At first blush, it seems to me that
>>>     the pointers `from_next`, `from_prev`, and `to_next` could be
>>>     on the stack and if so, will be on at least one cache line,
>>>     and possibly 2, if the call frame for `MoveElement` spans
>>>     more than one.  Of course, it's impossible to say when this
>>>     is compiled, but maybe you require that the stack is always
>>>     aligned to a cache line boundary or something.  Or maybe
>>>     these are all in registers and it's fine.
>>
>> AFAIK the stack accesses will use normal loads that won't be tracked for
>> conflicts, so they don't count towards the 8 cache-lines limit.
> 
> Ok, good to go.
> 
>>> 4. Depending on the size and alignment criteria of the the
>>>     `Element` structure and the placement of the `next` and
>>>     `prev` elements in the struct (unknowable from this example),
>>>     `to->next` may be on another cache line.
>>
>> The coder may need to be careful with such slot placement and
>> alignment, indeed.
> 
> Yup.  This could easily happen.  Consider,
> 
> #include <stdalign.h>
> #include <stdint.h>
> #include <stdio.h>
> 
> struct elem {
>          struct elem *next;
>          struct elem *prev;
>          uint32_t data;
> };
[...]

Indeed. Ideally, elem should be padded up to _and_ aligned on a l2 cache 
line boundary to help get rid of false sharing. Also, the "anchor" 
should be padded and aligned as well. An anchor can be:

struct anchor
{
     std::atomic<elem*> m_head;
};