[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxO1a5LNK64Zr5rEAz+XYSEhzVsY+JTq+W=i615TuBZiA@mail.gmail.com>
Date: Sat, 24 Sep 2016 13:47:38 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Matthew Wilcox <mawilcox@...rosoft.com>
Cc: Matthew Wilcox <mawilcox@...uxonhyperv.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Konstantin Khlebnikov <koct9i@...il.com>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
linux-mm <linux-mm@...ck.org>,
linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH 2/2] radix-tree: Fix optimisation problem
On Sat, Sep 24, 2016 at 1:21 PM, Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> That said, if this code isn't even used, as Konstantin says (THP
> selects it - doesn't THP use it?), then the fix really should be to
> just remove the odd code instead of adding to it.
>
> Looking around for uses that set "order" to anything but zero, I
> really don't see it. So maybe we should just do *that* trivial thing
> instead, and remove CONFIG_RADIX_TREE_MULTIORDER, since it's appears
> to be buggy and always has been.
IOW, a patch something like this?
NOTE! This is entirely untested. Things still seem to compile with it,
at least with some configurations. That's all I can say.
I do like this part:
11 files changed, 29 insertions(+), 518 deletions(-)
although admittedly 2/3rds of the deletions were for the multiorder
tests. But even if you ignore the test side, it's just fairly clean
removal of code that is apparently not used, and that was buggy.
Linus
View attachment "patch.diff" of type "text/x-patch" (26375 bytes)
Powered by blists - more mailing lists