Messages in this thread | | | Subject | Re: [PATCH 2/2] ipc,msg: provide barrier pairings for lockless receive | From | Davidlohr Bueso <> | Date | Thu, 04 Jun 2015 11:56:51 -0700 |
| |
On Thu, 2015-06-04 at 11:41 -0700, Davidlohr Bueso wrote: > On Thu, 2015-06-04 at 19:57 +0200, Manfred Spraul wrote: > > On 05/30/2015 02:03 AM, Davidlohr Bueso wrote: > > > We currently use a full barrier on the sender side to > > > to avoid receiver tasks disappearing on us while still > > > performing on the sender side wakeup. We lack however, > > > the proper CPU-CPU interactions pairing on the receiver > > > side which busy-waits for the message. Similarly, we do > > > not need a full smp_mb, and can relax the semantics for > > > the writer and reader sides of the message. This is safe > > > as we are only ordering loads and stores to r_msg. And in > > > both smp_wmb and smp_rmb, there are no stores after the > > > calls _anyway_. > > I like the idea, the pairing in ipc is not good. > > Another one is still open in sem. > > Hmm for sems are you referring to spinning on ->status in > get_queue_result() while another task is performing a wakeup in between > wake_up_sem_queue_prepare() and wake_up_sem_queue_do()? > > > > > Perhaps we should formalize it a bit more, so that it is easy to find > > which barrier pair belongs together. > > It is only an idea, but right now there are too many bugs. > > Good point, however, what do you think of the below instead? Makes it > crystal clear, imho.
We had to do some formalizing in futex too.
> + * Where (A) orders the message value read and where (B) orders > + * the write to the futex -- done in both pipelined_send and ^^ this should be r_msg
| |