Re: [lock-free] Linux membarrier syscall

[Joseph Seigh]

Ok, thanks.   I'll examine it in a bit more detail, though at first glance 
it looks like they're using ipi to speed things up by not having to wait 
for slower occurring kernel events.

I'm doing some work on  a hazard pointer based proxy collector w/ memory 
barriers that I suggested ages ago.  I posted some smrproxy timing 
comparisons 
.  
I was going to rework the atomic reference counted proxy collector in 
c11/c17 atomics as well but the approximated timings are so bad compared to 
smrproxy that I think I will pass on that.

Joe Seigh

On Tuesday, June 13, 2023 at 3:03:34 AM UTC-4 Dmitry Vyukov wrote:

> On Fri, Jun 9, 2023 at 8:00 AM Joseph Seigh  wrote:
> >
> > Anyone know the difference between MEMBARRIER_CMD_PRIVATE_EXPEDITED and 
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE for membarrier.
> >
> > It would be nice if it actually does what I think it does. I really 
> don't want to have to read from procfs and do a lot of parsing and such.
>
> Nice to see you here again, Joe
>
> The docs are quite cryptic:
> "all its running threads siblings have executed a core serializing 
> instruction":
>
> https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/membarrier.h#L155
>
> In reality it does this:
>
> https://elixir.bootlin.com/linux/latest/source/kernel/sched/membarrier.c#L322
>
> https://elixir.bootlin.com/linux/latest/source/kernel/sched/membarrier.c#L184
>
> which boils down to:
>
> https://elixir.bootlin.com/linux/latest/source/arch/x86/include/asm/sync_core.h#L42
>
> * This function forces the icache and prefetched instruction stream to
> * catch up with reality in two very specific cases:
> *
> * a) Text was modified using one virtual address and is about to be 
> executed
> * from the same physical page at a different virtual address.
> *
> * b) Text was modified on a different CPU, may subsequently be
> * executed on this CPU, and you want to make sure the new version
> * gets executed. This generally means you're calling this in an IPI.
>
>
> So it looks like it's intended for self-modifying code...
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/02316b45-8d28-49f3-af60-c49ae27518ban%40googlegroups.com.

Re: [lock-free] Linux membarrier syscall

[Dmitry Vyukov]

On Fri, Jun 9, 2023 at 8:00 AM Joseph Seigh  wrote:
>
> Anyone know the difference between MEMBARRIER_CMD_PRIVATE_EXPEDITED and 
> MEMBARRIER_CMD_PRIVATE_EXPEDITED_SYNC_CORE for membarrier.
>
> It would be nice if it actually does what I think it does.   I really don't 
> want to have to read from procfs and do a lot of parsing and such.

Nice to see you here again, Joe

The docs are quite cryptic:
"all its running threads siblings have executed a core serializing instruction":
https://elixir.bootlin.com/linux/latest/source/include/uapi/linux/membarrier.h#L155

In reality it does this:
https://elixir.bootlin.com/linux/latest/source/kernel/sched/membarrier.c#L322
https://elixir.bootlin.com/linux/latest/source/kernel/sched/membarrier.c#L184

which boils down to:
https://elixir.bootlin.com/linux/latest/source/arch/x86/include/asm/sync_core.h#L42

 * This function forces the icache and prefetched instruction stream to
 * catch up with reality in two very specific cases:
 *
 *  a) Text was modified using one virtual address and is about to be executed
 * from the same physical page at a different virtual address.
 *
 *  b) Text was modified on a different CPU, may subsequently be
 * executed on this CPU, and you want to make sure the new version
 * gets executed.  This generally means you're calling this in an IPI.


So it looks like it's intended for self-modifying code...

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"Scalable Synchronization Algorithms" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to lock-free+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/lock-free/CAEeQi3sdB0%2BrTodYvHXthgUV7xSh9iaEgGkuoJNP8c_z7gpH2g%40mail.gmail.com.