From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29456C77B70 for ; Mon, 17 Apr 2023 11:00:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229574AbjDQLAu (ORCPT ); Mon, 17 Apr 2023 07:00:50 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57822 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229992AbjDQLAo (ORCPT ); Mon, 17 Apr 2023 07:00:44 -0400 Received: from desiato.infradead.org (desiato.infradead.org [IPv6:2001:8b0:10b:1:d65d:64ff:fe57:4e05]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E4037ED; Mon, 17 Apr 2023 03:59:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; 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; bh=qAwfrPnNclTtYIr2T/WtfaYPceP7Audmu+SG7iP0hiY=; b=XFJZfNir+HHYcVnr91cef5KybD AFLuToNXZo4xhu6058jHimjaxx0DHbxStXUWvwKjdNg8Nm/KhmvEfiKdxhNK9M5OZh6m+Ohu9je10 wbLF0nlauqkCH50ncll7d5Ka8bBHL1vZm8tX+XY+mjeM2OcryOdBR9ObZmb1qgaz+1Zv/ZcdXFVMR ZdU8ht/KAIOFvJ5yqRDJPlAgBFn3MVfCjh3Q7WquD1yW3zplLbLsOS6FDTi01Fikid9AxAQ2WJnnb 4XwfWe/ruE8dmimQGaL6xRe+ccPp3WWw+p2WjNYvzUBBLJJ8vPpYFSv9R8nIUS50QdY8vcwRPFkhI 55o3Yp2Q==; Received: from j130084.upc-j.chello.nl ([24.132.130.84] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.96 #2 (Red Hat Linux)) id 1poMY4-00HIUt-2L; Mon, 17 Apr 2023 10:57:29 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 66D103001E5; Mon, 17 Apr 2023 12:57:27 +0200 (CEST) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 201D424248704; Mon, 17 Apr 2023 12:57:27 +0200 (CEST) Date: Mon, 17 Apr 2023 12:57:27 +0200 From: Peter Zijlstra To: Adrian Hunter Cc: Ingo Molnar , Arnaldo Carvalho de Melo , Mark Rutland , Alexander Shishkin , Jiri Olsa , Namhyung Kim , Ian Rogers , linux-perf-users@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH RFC 1/5] perf: Add ioctl to emit sideband events Message-ID: <20230417105727.GG83892@hirez.programming.kicks-ass.net> References: <20230414082300.34798-1-adrian.hunter@intel.com> <20230414082300.34798-2-adrian.hunter@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230414082300.34798-2-adrian.hunter@intel.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Apr 14, 2023 at 11:22:56AM +0300, Adrian Hunter wrote: > perf tools currently read /proc to get this information, but that > races with changes made by the kernel. > > Add an ioctl to output status-only sideband events for a currently > active event on the current CPU. Using timestamps, these status-only > sideband events will be correctly ordered with respect to "real" > sideband events. > > The assumption is a user will: > - open and enable a dummy event to track sideband events > - call the new ioctl to get sideband information for currently > running processes as needed > - enable the remaining selected events > > The initial sideband events to be supported will be: fork, namespaces, comm > and mmap. > > Add a new misc flag PERF_RECORD_MISC_STATUS_ONLY to differentiate "real" > sideband events from status-only sideband events. > > The limitation that the event must be active is significant. The ioctl > caller must either: > i) For a CPU context, set CPU affinity to the correct CPU. > Note, obviously that would not need to be done for system-wide > tracing on all CPUs. It would also only need to be done for the > period of tracing when the ioctl is to be used. > ii) Use an event opened for the current process on all CPUs. > Note, if such an additional event is needed, it would also use > additional memory from the user's perf_event_mlock_kb / > RLIMIT_MEMLOCK limit. Why would a single per-task event not work? I see nothing in the code that would require a per-task-per-cpu setup. Or am I just having trouble reading again?