[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiHPE3Q-qARO+vqbN0FSHwQXCYSmKcrjgxqVLJun5DjhA@mail.gmail.com>
Date: Tue, 15 Sep 2020 12:32:44 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthieu Baerts <matthieu.baerts@...sares.net>
Cc: Michael Larabel <Michael@...haellarabel.com>,
Matthew Wilcox <willy@...radead.org>,
Amir Goldstein <amir73il@...il.com>,
"Ted Ts'o" <tytso@...gle.com>,
Andreas Dilger <adilger.kernel@...ger.ca>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
Jan Kara <jack@...e.cz>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: Kernel Benchmarking
On Tue, Sep 15, 2020 at 12:26 PM Matthieu Baerts
<matthieu.baerts@...sares.net> wrote:
>
> I don't know if this info is useful but I just checked and I can
> reproduce the issue with a single CPU.
Good thinking.
> And the trace is very similar to the previous one:
.. and yes, now there are no messy traces, they all have that
__lock_page_killable() unambiguously in them (and the only '?' entries
are just from stale stuff on the stack which is due to stack frames
that aren't fully initialized and old stack frame data shining
through).
So it does seem like the previous trace uncertainty was likely just a
cross-CPU issue.
Was that an actual UP kernel? It might be good to try that too, just
to see if it could be an SMP race in the page locking code.
After all, one such theoretical race was one reason I started the rewrite.
Linus
Powered by blists - more mailing lists