[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiqzsK_c_jUXFnSXeumsRQpYEwv0Xbi3MiGKLcVxS2_kg@mail.gmail.com>
Date: Wed, 22 Jul 2020 17:23:03 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Hugh Dickins <hughd@...gle.com>, Oleg Nesterov <oleg@...hat.com>
Cc: Michal Hocko <mhocko@...nel.org>, Linux-MM <linux-mm@...ck.org>,
LKML <linux-kernel@...r.kernel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Michal Hocko <mhocko@...e.com>
Subject: Re: [RFC PATCH] mm: silence soft lockups from unlock_page
On Wed, Jul 22, 2020 at 4:42 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> NOTE NOTE NOTE! This is both somewhat subtle code, and ENTIRELY
> UNTESTED.
It seems to boot.
It adds more lines than it removes, but a lot of it is comments, and
while it's somewhat subtle, I think it's actually conceptually simpler
than what we had before.
The actual waiting loop itself, for example, is now entirely and
utterly trivial.
The DROP behavior is also a lot more straightforward and logical, imnsho.
The biggest annoyance I have with it is how it open-codes
"finish_wait()", and honestly, the "proper" fix for that would likely
be to simply instead make "finish_wait()" return the "did I need to
remove it from the list or not" value. That's the only reason that
patch open-codes it right now.
It _feels_ like the right solution to this thing.
But maybe that's just the "pee in the snow" effect, where I like it
only because I've put my mark on it.
So it would be good to get more opinions, and perhaps more testing
than my limited "it boots and works for me, and I can still build
kernels and run a browser".
Linus
Powered by blists - more mailing lists