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.
next prev parent 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