Message-ID: <1433444211.2320.29.camel@stgolabs.net>
Subject: Re: [PATCH 2/2] ipc,msg: provide barrier pairings for lockless
 receive
From: Davidlohr Bueso <dave@stgolabs.net>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Date: Thu, 04 Jun 2015 11:56:51 -0700
In-Reply-To: <1433443289.2320.26.camel@stgolabs.net>
References: <1432944186-7305-1-git-send-email-dave@stgolabs.net>
	 <1432944186-7305-2-git-send-email-dave@stgolabs.net>
	 <5570916D.4070008@colorfullife.com> <1433443289.2320.26.camel@stgolabs.net>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1807
Lines: 39

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/