All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Andrii Nakryiko <andrii.nakryiko@gmail.com>
Cc: Joel Fernandes <joel@joelfernandes.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	Andrii Nakryiko <andriin@fb.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	parri.andrea@gmail.com, will@kernel.org,
	Boqun Feng <boqun.feng@gmail.com>,
	npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk,
	luc.maranget@inria.fr, Akira Yokosawa <akiyks@gmail.com>,
	dlustig@nvidia.com, open list <linux-kernel@vger.kernel.org>,
	linux-arch@vger.kernel.org
Subject: Re: Some -serious- BPF-related litmus tests
Date: Fri, 29 May 2020 22:53:31 +0200	[thread overview]
Message-ID: <20200529205331.GV2483@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAEf4Bzb9D1jTdmUzopc35qmFopaW-UfvLO9ohFsFsBuLVm0ZCw@mail.gmail.com>

On Fri, May 29, 2020 at 01:01:51PM -0700, Andrii Nakryiko wrote:

> > question though; why are you using xchg() for the commit? Isn't that
> > more expensive than it should be?
> >
> > That is, why isn't that:
> >
> >   smp_store_release(&hdr->len, new_len);
> >
> > ? Or are you needing the smp_mb() for the store->load ordering for the
> > ->consumer_pos load? That really needs a comment.
> 
> Yeah, smp_store_release() is not strong enough, this memory barrier is
> necessary. And yeah, I'll follow up with some more comments, that's
> been what Joel requested as well.

Ok, great.

> > I think you can get rid of the smp_load_acquire() there, you're ordering
> > a load->store and could rely on the branch to do that:
> >
> >         cons_pos = READ_ONCE(&rb->consumer_pos) & rb->mask;
> >         if ((flags & BPF_RB_FORCE_WAKEUP) || (cons_pos == rec_pos && !(flags &BPF_RB_NO_WAKEUP))
> >                 irq_work_queue(&rq->work);
> >
> > should be a control dependency.
> 
> Could be. I tried to keep consistent
> smp_load_acquire/smp_store_release usage to keep it simpler. It might
> not be the absolutely minimal amount of ordering that would still be
> correct. We might be able to tweak and tune this without changing
> correctness.

We can even rely on the irq_work_queue() being an atomic, but sure, get
it all working and correct first before you wreck it ;-)

  reply	other threads:[~2020-05-29 20:53 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-22  0:38 Some -serious- BPF-related litmus tests Paul E. McKenney
2020-05-22  9:44 ` Peter Zijlstra
2020-05-22 10:56   ` Paul E. McKenney
2020-05-22 14:36     ` Alan Stern
2020-05-22 17:45       ` Paul E. McKenney
2020-05-22 14:32   ` Alan Stern
2020-05-22 17:43     ` Paul E. McKenney
2020-05-22 19:38       ` Andrii Nakryiko
2020-05-22 19:38         ` Andrii Nakryiko
2020-05-24 12:09         ` Akira Yokosawa
2020-05-25 18:31           ` Andrii Nakryiko
2020-05-25 22:01             ` Akira Yokosawa
2020-05-25 23:31               ` Andrii Nakryiko
2020-05-26 10:50                 ` Akira Yokosawa
2020-05-26 14:02                   ` Akira Yokosawa
2020-05-26 20:19                     ` Andrii Nakryiko
2020-05-26 23:00                       ` Akira Yokosawa
2020-05-27  0:09                         ` Andrii Nakryiko
2020-05-26 20:15                   ` Andrii Nakryiko
2020-05-26 22:23                     ` Akira Yokosawa
2020-05-25 11:25         ` Peter Zijlstra
2020-05-25 15:47           ` Paul E. McKenney
2020-05-25 17:02             ` Peter Zijlstra
2020-05-25 17:21               ` Paul E. McKenney
2020-05-25 17:45                 ` Paul E. McKenney
2020-05-28 22:00                 ` Joel Fernandes
2020-05-28 22:16                   ` Peter Zijlstra
2020-05-29  5:14                     ` Andrii Nakryiko
2020-05-29 12:36                       ` Peter Zijlstra
2020-05-29 20:01                         ` Andrii Nakryiko
2020-05-29 20:53                           ` Peter Zijlstra [this message]
2020-05-25 14:53         ` Boqun Feng
2020-05-25 18:38           ` Andrii Nakryiko
2020-05-28 21:48             ` Joel Fernandes
2020-05-29  4:38               ` Andrii Nakryiko
2020-05-29 17:23                 ` Joel Fernandes
2020-05-29 20:10                   ` Andrii Nakryiko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200529205331.GV2483@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akiyks@gmail.com \
    --cc=andrii.nakryiko@gmail.com \
    --cc=andriin@fb.com \
    --cc=boqun.feng@gmail.com \
    --cc=dhowells@redhat.com \
    --cc=dlustig@nvidia.com \
    --cc=j.alglave@ucl.ac.uk \
    --cc=joel@joelfernandes.org \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=npiggin@gmail.com \
    --cc=parri.andrea@gmail.com \
    --cc=paulmck@kernel.org \
    --cc=stern@rowland.harvard.edu \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.