Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp66662pxb; Wed, 14 Apr 2021 09:32:37 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxF1f/4NITAR9ECp+BwE6FYkmTuqQiT9Jz2KkaurG1u0oZarGe6Lu06IDKokgTfqNTjV9vr X-Received: by 2002:a17:906:6818:: with SMTP id k24mr19482978ejr.245.1618417957513; Wed, 14 Apr 2021 09:32:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618417957; cv=none; d=google.com; s=arc-20160816; b=y9JMI00I3jDOvhHIyeVLgzJelHioducM+NxRxgr+G02+NKrTZK6A2tLyZ75JeezyYM d3r5GGfILfCrj45TOYQGE+U1ppW3Gd8fG2mBbQawyWKHvKVM1L6PG1304dxKa0jAOUTI eGw7EnC0Bop0oAyfEEh7nooBx1nz47OJW3TUbGi0bcx8fdeEMzv8zQE+73ZcZgzsQ7/J qjqtxZqYFMpM69fMtgCCWrytJ/JRR9qgOBXqyI7/PF0/RAniQ0+BWbAP095fku5Le++C g5hcHXKDC8DSKWdxxXQWzjO0B6lvQupGy4ZD/578WkhkzWLpggPd/XwBC+YS/F3Y3ymi w0bA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=5h6OsbAMSXPK8wemWxu8bCmOmmVGKnMbC3h3Th4DKLQ=; b=Mhg8MsfnFp1eI+XYNsBBXDmGNFELgmMjtKy4i03NjAqhUPfUAwcpFfrh+2FUHE8doN jw1bFouo5xFHogPUGdQ2Yzxubr9t3vk/xmuw6nOtwj8OIQsGOpfjrlzDs7bLQ/d93gSr hB0VXx+AKx2MlI3IlACQzrzwMgcc6vpbEuR9VC2Sojkxom7ZIzO38Z2jDemgwzV87byr Pa06lHmdDS2RJQZH8fBQwWppYXa6D5LgBScAXfu2cBYvNE5w8cnw8XsJvvhI76bCVX64 Ar7K5iyndD7dhyKqaoSk0BQ6802IgTN+tnLEOMWIUFFkTN/HW687ws7yTO9JvU4Nh47w S6lA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i6si53031edu.313.2021.04.14.09.32.06; Wed, 14 Apr 2021 09:32:37 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231599AbhDNOKp (ORCPT + 99 others); Wed, 14 Apr 2021 10:10:45 -0400 Received: from mail.kernel.org ([198.145.29.99]:58458 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232646AbhDNOKn (ORCPT ); Wed, 14 Apr 2021 10:10:43 -0400 Received: from gandalf.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E185761166; Wed, 14 Apr 2021 14:10:20 +0000 (UTC) Date: Wed, 14 Apr 2021 10:10:19 -0400 From: Steven Rostedt To: Daniel Bristot de Oliveira Cc: linux-kernel@vger.kernel.org, kcarcia@redhat.com, Jonathan Corbet , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Alexandre Chartre , Clark Willaims , John Kacur , Juri Lelli , linux-doc@vger.kernel.org Subject: Re: [RFC PATCH 1/5] tracing/hwlat: Add a cpus file specific for hwlat_detector Message-ID: <20210414101019.7c5a66f6@gandalf.local.home> In-Reply-To: <94bbcd0e0f06b79aeb775e8dbf3a301f6679bb4c.1617889883.git.bristot@redhat.com> References: <94bbcd0e0f06b79aeb775e8dbf3a301f6679bb4c.1617889883.git.bristot@redhat.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 8 Apr 2021 16:13:19 +0200 Daniel Bristot de Oliveira wrote: > Provides a "cpus" interface to the hardware latency detector. By > default, it lists all CPUs, allowing hwlatd threads to run on any online > CPU of the system. > > It serves to restrict the execution of hwlatd to the set of CPUs writing > via this interface. Note that hwlatd also respects the "tracing_cpumask." > Hence, hwlatd threads will run only on the set of CPUs allowed here AND > on "tracing_cpumask." > > Why not keep just "tracing_cpumask"? Because the user might be interested > in tracing what is running on other CPUs. For instance, one might run > hwlatd in one HT CPU while observing what is running on the sibling HT > CPU. The cpu list format is also more intuitive. > > Also in preparation to the per-cpu mode. OK, I'm still not convinced that you couldn't use tracing_cpumask here. Because we have instances, and tracing_cpumask is defined per instance, you could simply do: # cd /sys/kernel/tracing # mkdir instances/hwlat # echo a > instances/hwlat/tracing_cpumask # echo hwlat > instances/hwlat/current_tracer Now the tracing_cpumask above only affects the hwlat tracer. I'm just reluctant to add more tracing files if the current ones can be used without too much trouble. For being intuitive, let's make user space tools hide the nastiness of the kernel interface ;-) -- Steve