From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753353AbbALOAm (ORCPT ); Mon, 12 Jan 2015 09:00:42 -0500 Received: from mga03.intel.com ([134.134.136.65]:40466 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751329AbbALOAj (ORCPT ); Mon, 12 Jan 2015 09:00:39 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,744,1413270000"; d="scan'208";a="649823290" From: Alexander Shishkin To: Peter Zijlstra Cc: "Metzger\, Markus T" , Ingo Molnar , "linux-kernel\@vger.kernel.org" , Robert Richter , Frederic Weisbecker , Mike Galbraith , Paul Mackerras , Stephane Eranian , Andi Kleen , "Liang\, Kan" , "Hunter\, Adrian" , "mathieu.poirier\@linaro.org" , "acme\@infradead.org" Subject: Re: [PATCH v8 02/14] perf: Add AUX area to ring buffer for raw data streams In-Reply-To: <20150112133841.GB25256@twins.programming.kicks-ass.net> References: <1415972627-37514-1-git-send-email-alexander.shishkin@linux.intel.com> <1415972627-37514-3-git-send-email-alexander.shishkin@linux.intel.com> <20150109151814.GP3337@twins.programming.kicks-ass.net> <87d26knnvp.fsf@ashishki-desk.ger.corp.intel.com> <20150112133841.GB25256@twins.programming.kicks-ass.net> User-Agent: Notmuch/0.17+49~gaa57e9d (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu) Date: Mon, 12 Jan 2015 16:00:28 +0200 Message-ID: <87a91onloj.fsf@ashishki-desk.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Peter Zijlstra writes: > On Mon, Jan 12, 2015 at 03:12:58PM +0200, Alexander Shishkin wrote: >> > I suppose we could; I'm trying to remember why I did it like this, I'm >> > failing to remember much past yesterday atm :/ >> >> Well, right now we can only map things in one order: user page + perf >> buffer, then aux buffer. Ideally, we can reduce it to mapping the user >> page first (always R/W), setting up the desired offsets for data and aux >> buffers and then mapping those in whatever order. And we can also have >> holes between them if we want (not sure if that's useful, though). > > Indeed, over the weekend I came up a similar argument. Suppose we want > to extend the thing with yet another area, at that point we simply do > not know which segment is meant to be mapp()ed. > > Breaking up the control page from the data buffer is indeed a sane > proposal. > >> If we want to stick to the current scheme of things where user page is >> mapped together with data, we should set up aux_{offset,size} in >> kernel's perf_mmap() path, similarly to data_{offset,size}. >> >> There is another problem with it, though: it makes it impossible to run >> the aux buffer in "full trace mode" (where we move the tail as we read >> the data out), while running the data buffer in overwrite mode, because >> the latter requires the user_page to be mapped RO => no way to update >> aux_tail for the user. > > ISTR aux bits relying on their own mmap(PROT_WRITE) bit, but yes-ish. It is. Now if data buffer is made to behave the same way, this problem goes away. Let me see if I can come up with a patch for this, bearing in mind backwards compatibility with older perfs etc. Regards, -- Alex