Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756269Ab3HWTjk (ORCPT ); Fri, 23 Aug 2013 15:39:40 -0400 Received: from mail.skyhub.de ([78.46.96.112]:39154 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755686Ab3HWTjj (ORCPT ); Fri, 23 Aug 2013 15:39:39 -0400 Date: Fri, 23 Aug 2013 21:39:34 +0200 From: Borislav Petkov To: Vince Weaver Cc: Robert Richter , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Jiri Olsa , linux-kernel@vger.kernel.org, Vince Weaver Subject: Re: [PATCH v3 12/12] [RFC] perf, persistent: ioctl functions to control persistency Message-ID: <20130823193934.GB15521@pd.tnic> References: <1377180807-12758-1-git-send-email-rric@kernel.org> <1377180807-12758-13-git-send-email-rric@kernel.org> <20130823091128.GA19548@nazgul.tnic> <20130823094556.GB10223@rric.localhost> <20130823104441.GD10223@rric.localhost> <20130823113400.GA20310@nazgul.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2047 Lines: 54 On Fri, Aug 23, 2013 at 01:07:54PM -0400, Vince Weaver wrote: > If I had not read the man-page fragment and saw a > result=ioctl(fd,PERF_EVENT_IOC_ATTACH,0); > I'd have no clue what it was doing (attach? attach to what?) > wheras if I saw > result=ioctl(fd,PERF_EVENT_IOC_UNPERSIST,0); > it's a little more clearer and also indicates that the ioctl is only > valid if you're dealing with a persistent event. Maybe this makes it more understandable for you but this is beside the point. The main and the most important idea here is that we want to attach/detach file descriptors to perf events and the resources (buffers, etc) associated with them so that those events can be made independent from processes. But I have to say the reversed thing above does sound confusing, now that I'm looking at the code. Actually, at the time we discussed this, my idea was to do it like this: 1. we open a perf event and get its file descriptor 2. ioctl ATTACH to it so that it is attached to the process. ... do some tracing and collecting and fiddling... 3. ioctl DETACH from it so that it is "forked in the background" so to speak, very similar to a background job in the shell. 4. The rest of the code continues and deallocates the event *BUT* (and this is the key thing!) the counter/tracepoint remains operational in the kernel, running all the time. 5. Now, after a certain point, you come back and ioctl ATTACH to this already opened event and read/collect its buffers again. And here's the deal - if you don't DETACH from the event at step 3, it gets destroyed on process exit, i.e. what the current perf behavior is. Robert, I think the above is more straight-forward and intuitive, no? Thanks. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/