Displaying 3 results from an estimated 3 matches for "dependent_ptr_smp_rmb".
Did you mean:
dependent_ptr_dma_rmb
2019 Jan 07
2
[PATCH RFC 3/4] barriers: convert a control to a data dependency
On 2019/1/3 ??4:57, Michael S. Tsirkin wrote:
> It's not uncommon to have two access two unrelated memory locations in a
> specific order. At the moment one has to use a memory barrier for this.
>
> However, if the first access was a read and the second used an address
> depending on the first one we would have a data dependency and no
> barrier would be necessary.
>
>
2019 Jan 07
2
[PATCH RFC 3/4] barriers: convert a control to a data dependency
On 2019/1/3 ??4:57, Michael S. Tsirkin wrote:
> It's not uncommon to have two access two unrelated memory locations in a
> specific order. At the moment one has to use a memory barrier for this.
>
> However, if the first access was a read and the second used an address
> depending on the first one we would have a data dependency and no
> barrier would be necessary.
>
>
2019 Jan 07
0
[PATCH RFC 3/4] barriers: convert a control to a data dependency
...> +
> > +#define dependent_ptr_mb(ptr, val) ({ mb(); (ptr); })
>
>
> So for the example of patch 4, we'd better fall back to rmb() or need a
> dependent_ptr_rmb()?
>
> Thanks
You mean for strongly ordered architectures like Intel?
Yes, maybe it makes sense to have dependent_ptr_smp_rmb,
dependent_ptr_dma_rmb and dependent_ptr_virt_rmb.
mb variant is unused right now so I'll remove it.
>
> > +
> > +#endif
> > +
> > #ifdef CONFIG_SMP
> > #ifndef smp_mb
> > diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> > i...