Received-SPF: pass (google.com: domain of linux-kernel+bounces-105268-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Date: Sat, 16 Mar 2024 14:20:02 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>, Masami Hiramatsu
 <mhiramat@kernel.org>, Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
 Beau Belgrave <beaub@linux.microsoft.com>, Chengming Zhou
 <zhouchengming@bytedance.com>, Huang Yiwei <quic_hyiwei@quicinc.com>, John
 Garry <john.g.garry@oracle.com>, Randy Dunlap <rdunlap@infradead.org>,
 Thorsten Blum <thorsten.blum@toblux.com>, Vincent Donnefort
 <vdonnefort@google.com>, linke li <lilinke99@qq.com>, Daniel Bristot de
 Oliveira <bristot@redhat.com>
Subject: Re: [GIT PULL] tracing: Updates for v6.9
Message-ID: <20240316142002.7480d74b@rorschach.local.home>
In-Reply-To: <CAHk-=wh5wWeib7+kVHpBVtUn7kx7GGadWqb5mW5FYTdewEfL=w@mail.gmail.com>
References: <20240315122934.1d3231ce@gandalf.local.home>
	<CAHk-=wg24KPFfeNwYdsD0e79MP4QhO3VaWkh0buPSD0M=141xQ@mail.gmail.com>
	<CAHk-=wh5wWeib7+kVHpBVtUn7kx7GGadWqb5mW5FYTdewEfL=w@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Sat, 16 Mar 2024 09:59:57 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Sat, 16 Mar 2024 at 09:31, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > So instead of merging a new feature that was mis-designed and is
> > already having code working around its mis-design, I'm not merging it
> > at all.  
> 
> Here's a clue: when hacking up VFS code, ask for ACK's from the VFS people.
> 
> And when hacking up MM code, make damn sure that you have VM people involved.
> 
> No more of this "random code that happens to work in my tests"
> garbage. Yes, I'm sure that others have done this same disgusting page
> counting hack and this was copied-and-pasted from some other

I admit that this was taken from looking at how other code did it.

> disgusting source, but because of all the history, I'm now looking at
> tracing pulls arefully, and I'm simply not allowing any broken hacks.

That's pretty obvious.

> 
> So in addition to getting actual VM people to help you with mapping
> stuff (hard requirement), I would also suggest:
> 
>  - your allocation has to be live over the whole mmap (and that's due
> to other fundamental issues - you're not even trying to deal with
> actual dynamic allocations and thank Cthulhu for that), and the code
> is literally designed that way, so then faulting pages in one at a
> time and refcounting them one at a time is just pointless and wrong.
> Just do it all at mmap time.
> 
>  - I'd suggest marking it all VM_DONTCOPY | VM_IO | VM_DONTEXPAND to
> not let people play games with the mapping.
> 
>  - avoid all the sub-page ref-counts entirely by using VM_PFNMAP, and
> use vm_insert_pages()
> 
> and a random note:
> 
>  - from a TLB pressure standpoint, it might be a good idea to try to
> keep the page table entries naturally aligned, so putting that one
> status page at the beginning is likely a bad idea. It will typically
> mean that hardware that can silently use larger TLB entries for
> aligned pages won't be able to do so.

This is actually something that I wanted to do, but how much to
allocate was stored in that status page. I could easily make the status
page as big as the sub-buffers themselves so that everything is
naturally aligned. The status pages states how big it is.

> 
> but the effect of that is likely fairly small.

I'm not going to be able to get this done this week, but I don't want
the other changes not to be pulled. As the ring buffer mappings near
the beginning, what do you want me to do in the mean time?

1) Rebase without them (I know how much you love rebasing)

2) revert the entire series.

3) Just make it disabled.

-- Steve