Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 24 May 2019 09:27:26 +0200
From:   Peter Zijlstra <peterz@infradead.org>
To:     Kris Van Hees <kris.van.hees@oracle.com>
Cc:     Alexei Starovoitov <alexei.starovoitov@gmail.com>,
        netdev@vger.kernel.org, bpf@vger.kernel.org,
        dtrace-devel@oss.oracle.com, linux-kernel@vger.kernel.org,
        rostedt@goodmis.org, mhiramat@kernel.org, acme@kernel.org,
        ast@kernel.org, daniel@iogearbox.net
Subject: Re: [RFC PATCH 00/11] bpf, trace, dtrace: DTrace BPF program type
 implementation and sample use
Message-ID: <20190524072726.GD2589@hirez.programming.kicks-ass.net>
References: <201905202347.x4KNl0cs030532@aserv0121.oracle.com>
 <20190521175617.ipry6ue7o24a2e6n@ast-mbp.dhcp.thefacebook.com>
 <20190522142531.GE16275@worktop.programming.kicks-ass.net>
 <20190522182215.GO2422@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20190522182215.GO2422@oracle.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Wed, May 22, 2019 at 02:22:15PM -0400, Kris Van Hees wrote:

> > Let me further NAK it for adding all sorts of garbage to the code --
> > we're not going to do gaps and stay_in_page nonsense.
> 
> Could you give some guidance in terms of an alternative?  The ring buffer code
> provides both non-contiguous page allocation support and a vmalloc-based
> allocation, and the vmalloc version certainly would avoid the entire gap and
> page boundary stuff.  But since the allocator is chosen at build time based on
> the arch capabilities, there is no way to select a specific memory allocator.
> I'd be happy to use an alternative approach that allows direct writing into
> the ring buffer.

So why can't you do what the regular perf does? Use an output iterator
that knows about the page breaks? See perf_output_put() for example.

Anyway, I agree with Alexei and DaveM, get it working without/minimal
kernel changes first, and then we can talk about possible optimizations.