All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Williamson <alex.williamson@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"lizhe.67@bytedance.com" <lizhe.67@bytedance.com>,
	Jason Gunthorpe <jgg@nvidia.com>,
	David Hildenbrand <david@redhat.com>
Subject: Re: [GIT PULL] VFIO updates for v6.17-rc1
Date: Mon, 4 Aug 2025 18:53:06 -0600	[thread overview]
Message-ID: <20250804185306.6b048e7c.alex.williamson@redhat.com> (raw)
In-Reply-To: <CAHk-=whhYRMS7Xc9k_JBdrGvp++JLmU0T2xXEgn046hWrj7q8Q@mail.gmail.com>

On Mon, 4 Aug 2025 16:55:09 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Mon, 4 Aug 2025 at 15:22, Alex Williamson <alex.williamson@redhat.com> wrote:
> >
> > Li Zhe (6):
> >       mm: introduce num_pages_contiguous()  
> 
> WHY?
> 
> There is exactly *ONE* user, why the heck do we introduce this
> completely pointless "helper" function, and put it in a core header
> file like it was worth it?

There was discussion here[1] where David Hildenbrand and Jason
Gunthorpe suggested this should be in common code and I believe there
was some intent that this would get reused.  I took this as
endorsement from mm folks.  This can certainly be pulled back into
subsystem code.

> And it's not like that code is some kind of work of art that we want
> to expose everybody to *anyway*. It's written in a particularly stupid
> way that means that it's *way* more expensive than it needs to be.
> 
> And then it's made "inline" despite the code generation being
> horrible, which makes it all entirely pointless.
> 
> Yes, I'm grumpy. This pull request came in late, I'm already
> traveling, and then I look at it and it just makes me *angry* at how
> bad that code is, and how annoying it is.

Sorry, I usually try to get in later during the first week to let the
dust settle a bit from the bigger subsystems, I guess I'm running a
little behind this cycle.  We'll get it fixed and I'll resend.  Thanks,

Alex

> My builds are already slower than usual because they happen on my
> laptop while traveling, I do *not* need to see this kind of absolutely
> disgusting code that does stupid things that make the build even
> slower.
> 
> So I refuse to pull this kind of crap.
> 
> If you insist on making my build slower and exposing these kinds of
> helper functions, they had better be *good* helper functions.
> 
> Hint: absolutely nobody cares about "the pages crossed a sparsemem
> border. If your driver cares about the number of contiguous pages, it
> might as well say "yeah, they are contiguous, but they are in
> different sparsemem chunks, so we'll break here too".
> 
> And at that point all you care about is 'struct page' being
> contiguous, instead of doing that disgusting 'nth_page'.
> 
> And then - since there is only *one* single user - you don't put it in
> the most central header file that EVERYBODY ELSE cares about.
> 
> And you absolutely don't do it if it generates garbage code for no good reason!
> 
>             Linus
> 

[1]https://lore.kernel.org/all/20250703111216.GG904431@ziepe.ca/


  reply	other threads:[~2025-08-05  0:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-04 22:22 [GIT PULL] VFIO updates for v6.17-rc1 Alex Williamson
2025-08-04 23:55 ` Linus Torvalds
2025-08-05  0:53   ` Alex Williamson [this message]
2025-08-05  7:47     ` David Hildenbrand
2025-08-05 11:49       ` Jason Gunthorpe
2025-08-05 12:07         ` David Hildenbrand
2025-08-05 12:38           ` Jason Gunthorpe
2025-08-05 12:41             ` David Hildenbrand
2025-08-05 12:56               ` Jason Gunthorpe
2025-08-05 13:05                 ` David Hildenbrand
2025-08-05 13:15                   ` Linus Torvalds
2025-08-05 13:19                     ` David Hildenbrand
2025-08-05 13:22                     ` David Hildenbrand
2025-08-05 13:00       ` Linus Torvalds
2025-08-05 13:20         ` David Hildenbrand
2025-08-05 13:24           ` David Hildenbrand
2025-08-05 13:28           ` Linus Torvalds
2025-08-05 13:37             ` David Hildenbrand
2025-08-05 13:49               ` Linus Torvalds
2025-08-05 13:25         ` Jason Gunthorpe
2025-08-05 13:33           ` David Hildenbrand
2025-08-05 13:55             ` Jason Gunthorpe
2025-08-05 14:10               ` David Hildenbrand
2025-08-05 14:20                 ` Jason Gunthorpe
2025-08-05 14:22                   ` David Hildenbrand
2025-08-05 14:24                     ` Jason Gunthorpe
2025-08-05 14:26                       ` David Hildenbrand
2025-08-05 13:36           ` Linus Torvalds
2025-08-05 13:47             ` David Hildenbrand
2025-08-05 13:51               ` Linus Torvalds
2025-08-05 13:55                 ` David Hildenbrand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250804185306.6b048e7c.alex.williamson@redhat.com \
    --to=alex.williamson@redhat.com \
    --cc=david@redhat.com \
    --cc=jgg@nvidia.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizhe.67@bytedance.com \
    --cc=torvalds@linux-foundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.