[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFy-cd6T+VeFV8WhegZXawzEFZEKN2U44-xLJRB4ww4s4w@mail.gmail.com>
Date: Tue, 8 Sep 2015 10:39:16 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Oleg Nesterov <oleg@...hat.com>
Cc: Al Viro <viro@...iv.linux.org.uk>,
Eric Dumazet <eric.dumazet@...il.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ingo Molnar <mingo@...nel.org>,
Maciej Żenczykowski <maze@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 3/3] Revert "task_work: remove fifo ordering guarantee"
On Tue, Sep 8, 2015 at 10:14 AM, Oleg Nesterov <oleg@...hat.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?
The other patches I do like - why add those list operations that are
just guaranteed to mess up the cache to add the file descriptors to
the workqueue list, when we can just do the operation directly? So I
think that's a separate issue.
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists