From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751509AbdIMMCi (ORCPT ); Wed, 13 Sep 2017 08:02:38 -0400 Received: from mga11.intel.com ([192.55.52.93]:26047 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751015AbdIMMCh (ORCPT ); Wed, 13 Sep 2017 08:02:37 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,387,1500966000"; d="scan'208";a="899833581" From: Alexander Shishkin To: Borislav Petkov Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, acme@redhat.com, kirill.shutemov@linux.intel.com, rric@kernel.org Subject: Re: [RFC PATCH 00/17] perf: Detached events In-Reply-To: <20170906162414.djyec6rlu2ktzdag@pd.tnic> References: <20170905133026.13689-1-alexander.shishkin@linux.intel.com> <20170906162414.djyec6rlu2ktzdag@pd.tnic> User-Agent: Notmuch/0.23.7 (http://notmuchmail.org) Emacs/25.1.1 (x86_64-pc-linux-gnu) Date: Wed, 13 Sep 2017 14:54:02 +0300 Message-ID: <87a81yx19h.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 Borislav Petkov writes: > On Tue, Sep 05, 2017 at 04:30:09PM +0300, Alexander Shishkin wrote: >> Detached events: a new flag to the perf syscall makes a 'detached' event, >> which exists after its file descriptor is released. Not all detached events >> are per-thread AUX events: this tries to take into account the need for >> system-wide persistent events too. > > Nice, thanks! Forgot to mention that I did hack the tracepoint support into the tooling as well to make sure it's a workable idea. >> (2) Need to be able to kill those events, so they need to be accessible >> after they are created. >> Event files: detached events exist as files in tracefs (at the moment), can >> be opened/mmaped/read/removed. > > I guess I'll see when I continue reading but I remember us doing ioctls > on the event fd. Iirc that was for re-attaching to the event to make it 'normal' before closing. >> (6) Ring buffer memory accounting needs to take this new arrangement into >> account: one user can use up at most NR_CPUS * buffer_size memory at any >> given point in time. >> Only account the first such event and undo the accounting when the last >> event is gone. > > ... and I guess we probably shouldn't allow the user to create too many > events and shoot herself in the OOM-foot. Well, they are still limited by the RLIMIT_MEMLOCK and perf_event_mlock sysctl for the total amount of memory that can be pinned for the ring buffers at any given time, so that should be fine. >> (7) We'll also need to supply all the things that the [PT] decoder normally >> finds out via sysfs attributes, like clock ratios, capabilities, etc so that >> it also finds its way into the core dump file. >> "PMU info" structure is appended to the user page. >> >> I've also hack the perf tool to support all this, all these things can be >> found at [1]. I'm not posting the tooling patches though, them being >> thoroughly ugly and proof-of-concept. In short, perf record will create >> detached events with '--detached' and afterwards will open detached events >> via their path in tracefs. > > Sounds nice. I'd need to test all that just so I can be able to create > detached RAS events (which are tracepoints) with it. Thanks, let me know how it goes. Regards, -- Alex