Received: by 10.213.65.68 with SMTP id h4csp1436928imn; Thu, 29 Mar 2018 04:55:56 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/3IGcRGsZsZ6X+Cf505langylCh0y2uy0yxP12EalCQuhb1gAW+RiAa9zVxkIYcvL+vRWP X-Received: by 2002:a17:902:8287:: with SMTP id y7-v6mr8044085pln.85.1522324556287; Thu, 29 Mar 2018 04:55:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522324556; cv=none; d=google.com; s=arc-20160816; b=brZvc3pP7AP8fyCdJC3g8+z7nZxJbxXkfjaWCaz4xKvl9vTVPQq5gcWhalmHTXXN0r ec2yBa2UuLai4Mo3jAhHYZtWoPQAVIjWwn8F52Ir1DX8cd+Ike3mSs2806Q6mPsbZPng fbOlG7YpNvmmrahod4O25oY0PclgCcX2IavxnbZLhFt8d5uXwqQwQo3OHi7kZlrC4avM ih4SBaxEYqqhVwiF35KXKQRDLW3WNwWYLkbZGOR1I1z1PjRh/UWFGSM9yuvFi97YDs0C Dgf3+HKMQRrEV0Ep6VduWYSNVhXC7HbUe2Gx25NvSfwskdbREU+KmSKMf7ntsH6lxHxQ vREw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=f/ozqw7SjdevS1ZuT9D2BJGm82rtNSU9SW5N01qRL1c=; b=lSrEIR1/raJfZ1KY0YwSc9GSCQOv9wDDngcsFKCxl9wtK5Xvb+JYTDTZ9X9FzoHOlr QmXz438fQbTT0dYpcW2N8TdFZ6+pBNCnZ1a+VoacJOJk7ABieh9cZRPSmupmM4wXcqxe GmfnblU+gPCZQl0Xo5Bi9hlVZz6o+7M8ENA4Vkl5vNlMNE4MUqrA0MlgR1jNdCChKLJE SZxcoRTLGP5rpLoYXuxWA92DVQxmQkV+EBiq0HRrVMYCgPZbTlDU6OL+75DFAMmpSAVH UfN1OwLx5xdufTMe4rHsdAGuSq+CriG3lUCkNtQwonq3AFb1f5f9SQ+Cgrx16nepYiku J26Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=WgxU4oWO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t9si3941632pgn.781.2018.03.29.04.55.42; Thu, 29 Mar 2018 04:55:56 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=WgxU4oWO; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753358AbeC2Lyn (ORCPT + 99 others); Thu, 29 Mar 2018 07:54:43 -0400 Received: from merlin.infradead.org ([205.233.59.134]:34212 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753278AbeC2Lyk (ORCPT ); Thu, 29 Mar 2018 07:54:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f/ozqw7SjdevS1ZuT9D2BJGm82rtNSU9SW5N01qRL1c=; b=WgxU4oWOrvpMu9EvChaoPjH8f 1labiH07DmZEnCkxc4upUbn3R9iFHeNUkIH4H43Ostp1zg9B+HXPsC0NwQ086e0cA8Ssqj+v+oT6N jKsheW2nkDfSac+V0rg42kFszP0HN+1bnpR8TI1mtvfEclzhWyhBerbVcRLTWeKyrr1r34bpC96sF 9jb9z5JJB3D/9xPrstQ9wEqO5IuSyN73ov1cBlhBuCK37v1dL+U6vv+AdXZmr0MC0e+n11eWkB9Tg LfKM1a4/Q6tRXVL8WWpFBK8fCKRu0L+sPTa4caFCYdjwvH8ME/34HN9kn8tt97wwo67qwf/oJeB/3 +6vl36Row==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1f1W8V-0008QM-3Y; Thu, 29 Mar 2018 11:54:31 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id C5046205C2CAC; Thu, 29 Mar 2018 13:54:29 +0200 (CEST) Date: Thu, 29 Mar 2018 13:54:29 +0200 From: Peter Zijlstra To: Alexander Shishkin Cc: Arnaldo Carvalho de Melo , Ingo Molnar , linux-kernel@vger.kernel.org, Will Deacon , Adrian Hunter , Markus Metzger Subject: Re: [PATCH] perf: Allow suppressing AUX records Message-ID: <20180329115429.GX4043@hirez.programming.kicks-ass.net> References: <20171115120022.o7hmfdb7vpeikvjl@hirez.programming.kicks-ass.net> <20180115150020.8509-1-alexander.shishkin@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180115150020.8509-1-alexander.shishkin@linux.intel.com> User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jan 15, 2018 at 05:00:20PM +0200, Alexander Shishkin wrote: > It has been pointed out to me many times that it is useful to be able > to switch off AUX records to save the bandwidth for records that actually > matter, for example, in AUX overwrite mode. > > The usefulness of PERF_RECORD_AUX is in some of its flags, like the > TRUNCATED flag that tells the decoder where exactly gaps in the trace are. > The OVERWRITE flag, on the other hand will be set on every single record > in overwrite mode. However, a PERF_RECORD_AUX[flags=OVERWRITE] is > generated on every target task's sched_out, which over time adds up to > a lot of useless information. > > In case the existing userspace depends on AUX records in the overwrite > mode, we preserve the original behavior and add an opt-in for the new > behavior, wherein the 'useless' records get suppressed. > > This patch adds an attribute bit to the described effect. > > Signed-off-by: Alexander Shishkin > Cc: Markus Metzger > Cc: Adrian Hunter > --- > include/uapi/linux/perf_event.h | 3 ++- > kernel/events/core.c | 5 +++++ > kernel/events/ring_buffer.c | 13 +++++++++++-- > 3 files changed, 18 insertions(+), 3 deletions(-) > > diff --git a/include/uapi/linux/perf_event.h b/include/uapi/linux/perf_event.h > index c77c9a2ebbbb..d7a981130561 100644 > --- a/include/uapi/linux/perf_event.h > +++ b/include/uapi/linux/perf_event.h > @@ -370,7 +370,8 @@ struct perf_event_attr { > context_switch : 1, /* context switch data */ > write_backward : 1, /* Write ring buffer from end to beginning */ > namespaces : 1, /* include namespaces data */ > - __reserved_1 : 35; > + suppress_aux : 1, /* don't generate PERF_RECORD_AUX */ > + __reserved_1 : 34; > > union { > __u32 wakeup_events; /* wakeup every n events */ So I'm basically fine with this patch, however I wonder if we really need this suppress flag and can't just unconditionally drop these events. Ash said that as far as he knows no Intel-PT user actually relies on it; Will is there anything ARM that is known to rely on them? In anycase, tentative ACK on this, unless we wants to be brave and forgo this flag. Ingo, any opinions? > diff --git a/kernel/events/core.c b/kernel/events/core.c > index 4e1a1bf8d867..6245a88c2bda 100644 > --- a/kernel/events/core.c > +++ b/kernel/events/core.c > @@ -10012,6 +10012,11 @@ SYSCALL_DEFINE5(perf_event_open, > goto err_context; > } > > + if (attr.suppress_aux && !pmu->setup_aux) { > + err = -EINVAL; > + goto err_context; > + } > + > /* > * Look up the group leader (we will attach this event to it): > */ > diff --git a/kernel/events/ring_buffer.c b/kernel/events/ring_buffer.c > index 141aa2ca8728..381f080e6409 100644 > --- a/kernel/events/ring_buffer.c > +++ b/kernel/events/ring_buffer.c > @@ -426,6 +426,12 @@ static bool __always_inline rb_need_aux_wakeup(struct ring_buffer *rb) > return false; > } > > +/* > + * These flags won't generate a PERF_RECORD_AUX on their own if > + * attr::suppress_aux is set. > + */ > +#define SUPPRESSABLE_FLAGS PERF_AUX_FLAG_OVERWRITE > + > /* > * Commit the data written by hardware into the ring buffer by adjusting > * aux_head and posting a PERF_RECORD_AUX into the perf buffer. It is the > @@ -460,8 +466,11 @@ void perf_aux_output_end(struct perf_output_handle *handle, unsigned long size) > * Only send RECORD_AUX if we have something useful to communicate > */ > > - perf_event_aux_event(handle->event, aux_head, size, > - handle->aux_flags); > + if (!handle->event->attr.suppress_aux || > + (handle->aux_flags & ~(u64)SUPPRESSABLE_FLAGS)) { > + perf_event_aux_event(handle->event, aux_head, size, > + handle->aux_flags); > + } > } > > rb->user_page->aux_head = rb->aux_head; > -- > 2.15.1 >