[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wiQ=9g=+A8LPWhPj9yRXFzf=tJKw1Cy-wpj1N9FKu-65w@mail.gmail.com>
Date: Tue, 5 Aug 2025 16:15:15 +0300
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: David Hildenbrand <david@...hat.com>
Cc: Jason Gunthorpe <jgg@...dia.com>, Alex Williamson <alex.williamson@...hat.com>,
"kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"lizhe.67@...edance.com" <lizhe.67@...edance.com>
Subject: Re: [GIT PULL] VFIO updates for v6.17-rc1
On Tue, 5 Aug 2025 at 16:05, David Hildenbrand <david@...hat.com> wrote:
>
> So I don't like the idea of micro-optimizing num_pages_contiguous() by
> adding weird tweaks to the core for that.
Seriously - take a look at that suggested sequence I posted, and tell
me that it isn't *MORE* obvious than the horror that is nth_page().
Honestly, if anybody thinks nth_page() is obvious and good, I think
they have some bad case of Stockholm syndrome.
This isn't about micro-optimizing. This is about not writing complete
garbage code that makes no sense.
nth_page() is a disgusting thing that is designed to look up
known-contiguous pages. That code mis-used it for *testing* for being
contiguous. It may have _worked_, but it was the wrong thing to do.
nth_page() in general should just not exist. I don't actually believe
there is any valid reason for it. I do not believe we should actually
have valid consecutive allocations of pages across sections.
So please work on removing that eldritch horror, not adding new worse
versions of it.
Linus
Powered by blists - more mailing lists