On 11.01.22 г. 16:00 ч., Steven Rostedt wrote:
On Tue, 11 Jan 2022 15:07:06 +0200 Yordan Karadzhov<y.karadz@xxxxxxxxx> wrote:On 10.01.22 г. 17:20 ч., Steven Rostedt wrote:On Mon, 10 Jan 2022 15:32:16 +0200 Yordan Karadzhov<y.karadz@xxxxxxxxx> wrote:Hi Steven On 18.12.21 г. 1:26 ч., Steven Rostedt wrote:From: "Steven Rostedt (VMware)"<rostedt@xxxxxxxxxxx> Add a set_affinity API that can let the user set what CPUs to enable tracing on.For the sake of completeness we will need APIs to 'clear' and 'get' the CPU affinity as well.For "clear" you mean to avoid a CPU(s), not clear the mask, right?I mean clear the mask. This will be a very simple method. The only argument will be the instance. And inside the method you just call 'tracefs_instance_file_clear()'. The 'get' method can return the bit mask of the CPUs.But why would anyone clear it? It doesn't make any sense. This mask is the CPUs that tracing is allowed on. By clearing it, you basically stopped all tracing. If anything, it would confuse people. I honestly do not know of a single use case (besides testing the tracing infrastructure) for clearing the entire mask. It would be similar to clearing the affinity mask for a task or interrupt. If anything, that could harm the system. I'm not even sure it's allowed (it would fail if tried). Now, I could see clearing specific CPUs, and that would be useful. Say you want to trace the entire system, but you dedicated a CPU for the tracing application. It would make sense to clear the CPUs that your tracing application is on and leave all others intact. That way the tracing application doesn't affect the results as much.
Sorry about my confusion, you are right.Clearing the mask or setting all bits to 0 makes no sense. What I wanted to have is the exact opposite. I want an API that restores the default configuration (sets all bits to 1).
Maybe 'reset' is a better name in this case. Thanks! Yordan
|