From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751992AbdJFLbv (ORCPT ); Fri, 6 Oct 2017 07:31:51 -0400 Received: from mga14.intel.com ([192.55.52.115]:33066 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751774AbdJFLbu (ORCPT ); Fri, 6 Oct 2017 07:31:50 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,483,1500966000"; d="scan'208";a="907405626" From: Alexander Shishkin To: Peter Zijlstra Cc: Peter Zijlstra , Ingo Molnar , linux-kernel@vger.kernel.org, acme@redhat.com, kirill.shutemov@linux.intel.com, rric@kernel.org, alexander.shishkin@linux.intel.com Subject: Re: [RFC PATCH 05/17] perf: Introduce detached events In-Reply-To: <20171003143438.e4xfwcv7sl4mtplx@hirez.programming.kicks-ass.net> References: <20170905133026.13689-1-alexander.shishkin@linux.intel.com> <20170905133026.13689-6-alexander.shishkin@linux.intel.com> <20171003143438.e4xfwcv7sl4mtplx@hirez.programming.kicks-ass.net> User-Agent: Notmuch/0.23.7 (http://notmuchmail.org) Emacs/25.1.1 (x86_64-pc-linux-gnu) Date: Fri, 06 Oct 2017 14:23:03 +0300 Message-ID: <87tvzctt9k.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: > So I'm not opposed to the idea of creating events that live independent > from of file descriptors. And stuffing them in a filesystem makes sense. > However I'm not entire convinced on the details. > > The above has a number of problems: > > - there's a filesystem race; two concurrent syscalls can try and create > the same file. In that case the error most certainly is not -ENOMEM. Indeed. > - there's a hash collision, similar issue. > > - there's some asymmetry in the create/destroy; that is you create the > file with sys_perf_event_open() and remove it with unlink(). There is also an ioctl() to turn it into a normal event fd that can then be closed. > - the actual name is very opaque and hard to use; how would a tool find > the right event to open? They can readlink("/proc/self/fd/$fd"), something that I hacked into the perf tool as well, although, truth be told I didn't actually need it for anything, partly because it's not a useful name. One use case that I could think of would be a task that's inherited a detached event wanting to get rid of it. They can scan their /proc/$pid/maps, find the vma by name and use that to locate the file. > Would it instead make sense to allow the user to creat() their own files > in this filesystem (with whatever descriptive name they need) and then > pass that fd like: > > sys_perf_event_open(.group_fd=fd, .flags=PERF_FLAG_FD_DETACH); > > or something to associate the file with the event. Of course, that makes > it very hard to create detached cgroup events :/ Yes, I like the idea of moving the burden of naming to the userspace, but then we have a problem with inheritance, which would still produce new events w/o user's input. Maybe use a directory for the 'parent' event? Then the above would still work. Regards, -- Alex