lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210414101019.7c5a66f6@gandalf.local.home>
Date:   Wed, 14 Apr 2021 10:10:19 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Daniel Bristot de Oliveira <bristot@...hat.com>
Cc:     linux-kernel@...r.kernel.org, kcarcia@...hat.com,
        Jonathan Corbet <corbet@....net>,
        Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Alexandre Chartre <alexandre.chartre@...cle.com>,
        Clark Willaims <williams@...hat.com>,
        John Kacur <jkacur@...hat.com>,
        Juri Lelli <juri.lelli@...hat.com>, linux-doc@...r.kernel.org
Subject: Re: [RFC PATCH 1/5] tracing/hwlat: Add a cpus file specific for
 hwlat_detector

On Thu,  8 Apr 2021 16:13:19 +0200
Daniel Bristot de Oliveira <bristot@...hat.com> 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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ