From: Oleg Nesterov <oleg@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "Al Viro" <viro@zeniv.linux.org.uk>,
"Eric Dumazet" <eric.dumazet@gmail.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Ingo Molnar" <mingo@kernel.org>,
"Maciej Żenczykowski" <maze@google.com>,
"Peter Zijlstra" <peterz@infradead.org>,
"Thomas Gleixner" <tglx@linutronix.de>,
"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] Revert "task_work: remove fifo ordering guarantee"
Date: Wed, 9 Sep 2015 15:16:42 +0200 [thread overview]
Message-ID: <20150909131642.GA28537@redhat.com> (raw)
In-Reply-To: <CA+55aFy-cd6T+VeFV8WhegZXawzEFZEKN2U44-xLJRB4ww4s4w@mail.gmail.com>
sorry for delay,
On 09/08, Linus Torvalds wrote:
>
> On Tue, Sep 8, 2015 at 10:14 AM, Oleg Nesterov <oleg@redhat.com> wrote:
> >
> > Now that fput() can't abuse ->task_works list, we can restore the FIFO
> > ordering. Yes, currently there are no in-kernel users which need this,
> > but I think task_work_add() will have more users and FIFO makes more
> > sense if (unlike fput/mntput) the callbacks change the task's state.
>
> So quite frankly, regardless of the other patches, I'd almost rather
> see the workqueue not being ordered. I don't think anybody pointed at
> any code that could possibly care. And if nobody cares, why add the
> code and the CPU cycles to do this?
Currently nobody cares, yes. IIRC, even the out-of-tree code I know about,
although I didn't recheck.
Again, rightly or not I believe that FIFO makes task_work_add() more useful.
Perhaps I am wrong, so far I can only provide the artificial examples...
To me this does not differ from, say, stop_one_cpu_nowait(). I would be
surprised if it wasn't FIFO.
At least this should be cheap after 1/3. And in any case the time we spend
in the "reverse" loop is nothing compared to the next one which actually
runs the callbacks.
Thanks. Lets see what Al thinks...
Oleg.
next prev parent reply other threads:[~2015-09-09 13:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-08 17:14 [PATCH 0/3] task_work: restore fifo ordering guarantee Oleg Nesterov
2015-09-08 17:14 ` [PATCH 1/3] fput: don't abuse task_work_add() when possible Oleg Nesterov
2015-09-08 17:14 ` [PATCH 2/3] fput: move ->f_next_put into a union with ->f_version Oleg Nesterov
2015-09-08 17:14 ` [PATCH 3/3] Revert "task_work: remove fifo ordering guarantee" Oleg Nesterov
2015-09-08 17:39 ` Linus Torvalds
2015-09-08 17:41 ` Linus Torvalds
2015-09-09 13:16 ` Oleg Nesterov [this message]
2015-09-09 16:17 ` Linus Torvalds
2015-09-09 16:43 ` Oleg Nesterov
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=20150909131642.GA28537@redhat.com \
--to=oleg@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=eric.dumazet@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=maze@google.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
/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