mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: peterz@infradead.org
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Christoph Hellwig" <hch@lst.de>,
	"Ingo Molnar" <mingo@kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Will Deacon" <will@kernel.org>,
	"Paul E. McKenney" <paulmck@kernel.org>,
	"Jens Axboe" <axboe@kernel.dk>,
	"Chris Wilson" <chris@chris-wilson.co.uk>,
	"David Miller" <davem@davemloft.net>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Frédéric Weisbecker" <fweisbec@gmail.com>,
	"Oleg Nesterov" <oleg@redhat.com>,
	"Vincent Guittot" <vincent.guittot@linaro.org>
Subject: Re: [RFC][PATCH v2 08/10] smp,irq_work: Use the new irq_work API
Date: Wed, 19 Aug 2020 21:41:16 +0200	[thread overview]
Message-ID: <20200819194116.GJ2674@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAHk-=wgMATDQQxLSsgmxCoCqApVXVeRnGOf6iWjnYdTJY_R3aw@mail.gmail.com>

On Wed, Aug 19, 2020 at 11:50:55AM -0700, Linus Torvalds wrote:
> On Wed, Aug 19, 2020 at 12:22 AM <peterz@infradead.org> wrote:
> >
> > That is, the external serialization comes from the non-atomic
> > test-and-set they both have. This works nicely when there is external
> > state that already serializes things, but totally comes apart (and
> > causes trivial list corruption) when you get it wrong.
> 
> Quite often, there just isn't any *need* for serialization, because
> there is only ever one op active.
> 
> That can be either because the csd is fundamentally a single thing ("I
> will transfer this object to another CPU"), or it can be because the
> CSD is already per-cpu (ie smp_call_function_single).

Note that smp_call_function_single() doesn't use _async(), and while it
does use per-cpu CSDs, the reqular .wait=false case then potentially
waits before (instead of after) in the unlikely case the local CSD was
already taken.

This makes that we cannot use it with IRQs disabled.

> You seem to make that common situation much worse.

Probably -- like I said, I'm not really happy with this either.

> Not only do you add that expensive atomic op, you add that expensive
> "use irq_work queues" for something that doesn't _need_ to use them.

I'm not sure I get the "expensive irq_work queues" argument, I fully
agree with you that adding the atomic op is fairly crap.

The remote irq_work is exactly same llist and IPI vector as remote
smp_call_function_single(). And the new irq_work_queue_remote_static()
is exactly as cheap as smp_call_function_single_async() for not having
an atomic op, queues to the same llist, sends the same IPI, but uses the
embedded data structure instead of pass a data pointer pattern.

Because most of the async users end up having another data structure to
pass arguments around anyway.

> I have to say, I'm not a fan. What are the real advantages? Your
> listed disadvantages are very very questionable.
> 
> IOW, what are the actual examples of "totally comes apart" that justifies this?
> 
> If the example is theoretical ("if you use csd's wrong") then I think
> they are worthless.

Well, I did use the CSD's wrong. I forgot the gotcha and made a mess of
things and stuff crashed, the wreckage is in the git history :/ I fixed
it, but I got burned.

I then went and looked at a bunch of other _async users and it wasn't
immediately obvious that they were doing it right (they were).

I wanted to improve things, but I'm willing to admit to just making it
worse in these last few patches.

Anyway, the pattern I wanted is more easily expressed with the new
irq_work_queue_remote(), even though I don't need it anymore. I can
throw away all the patches after that without loosing too much sleep.

  reply	other threads:[~2020-08-19 19:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18 10:51 [PATCH v2 00/10] smp: irq_work / smp_call_function rework Peter Zijlstra
2020-08-18 10:51 ` [PATCH v2 01/10] irq_work: Cleanup Peter Zijlstra
2020-08-18 10:51 ` [PATCH v2 02/10] smp: Cleanup smp_call_function*() Peter Zijlstra
2020-08-18 10:51 ` [PATCH v2 03/10] irq_work: Optimize irq_work_single() Peter Zijlstra
2020-08-18 10:51 ` [PATCH v2 04/10] irq_work: Unconditionally build on SMP Peter Zijlstra
2020-08-18 10:51 ` [PATCH v2 05/10] irq_work: Provide irq_work_queue_remote() Peter Zijlstra
2020-08-18 10:51 ` [RFC][PATCH v2 06/10] irq_work: Provide irq_work_queue_remote_static() Peter Zijlstra
2020-08-18 10:51 ` [RFC][PATCH v2 07/10] sched/fair: Exclude the current CPU from find_new_ilb() Peter Zijlstra
2020-08-18 10:51 ` [RFC][PATCH v2 08/10] smp,irq_work: Use the new irq_work API Peter Zijlstra
2020-08-18 16:25   ` Christoph Hellwig
2020-08-19  7:22     ` peterz
2020-08-19 18:50       ` Linus Torvalds
2020-08-19 19:41         ` peterz [this message]
2020-08-19 22:04           ` Linus Torvalds
2020-08-20 13:08             ` peterz
2020-08-20  6:20         ` Christoph Hellwig
2020-08-20  6:19   ` Christoph Hellwig
2020-08-20 13:40     ` peterz
2020-09-09  8:03       ` Christoph Hellwig
2020-08-18 10:51 ` [RFC][PATCH v2 09/10] smp: Make smp_call_function_single_async() safer Peter Zijlstra
2020-08-18 10:51 ` [RFC][PATCH v2 10/10] irq_work: Add a few comments Peter Zijlstra
2020-08-18 15:52   ` Randy Dunlap

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=20200819194116.GJ2674@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=axboe@kernel.dk \
    --cc=chris@chris-wilson.co.uk \
    --cc=davem@davemloft.net \
    --cc=fweisbec@gmail.com \
    --cc=hch@lst.de \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=paulmck@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=vincent.guittot@linaro.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome