[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFyMkd8EaozxvAZo9i3ArKh7m6HLjsUB34xnDBzXz4gowg@mail.gmail.com>
Date: Tue, 15 Aug 2017 15:56:14 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Andi Kleen <ak@...ux.intel.com>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>, Kan Liang <kan.liang@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Johannes Weiner <hannes@...xchg.org>, Jan Kara <jack@...e.cz>,
linux-mm <linux-mm@...ck.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] sched/wait: Break up long wake list walk
On Tue, Aug 15, 2017 at 3:47 PM, Davidlohr Bueso <dave@...olabs.net> wrote:
>
> Or you can always use wake_qs; which exists _exactly_ for the issues you
> are running into
Except they really don't actually work for this case, exactly because
they also simplify away "minor" details like exclusive vs
non-exclusive etc.
The page wait-queue very much has a mix of "wake all" and "wake one" semantics.
But I guess we could have two queues per page hash - one that is
wake-once, and one that is wake-all.
Which might solve the technical problem.
And if somebody then rewrote the swait code to not use the
unbelievably broken and misleading naming, it might even be
acceptable.
But as is, that swait code is broken shit, and absolutely does *not*
need new users. We got rid of one user, and the KVM people already
admitted that one of the remaining users is broken and doesn't
actually want swait at all and should use "wake_up_process()" instead
since there is no actual queuing going on.
In the meantime, stop peddling crap. That thing really is broken.
Linus
Powered by blists - more mailing lists