[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <89733d35-0b71-615f-4fb8-55183585c67a@intel.com>
Date: Tue, 18 Apr 2023 09:18:49 +0300
From: Adrian Hunter <adrian.hunter@...el.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Ingo Molnar <mingo@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>,
Namhyung Kim <namhyung@...nel.org>,
Ian Rogers <irogers@...gle.com>,
linux-perf-users@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC 0/5] perf: Add ioctl to emit sideband events
On 17/04/23 14:02, Peter Zijlstra wrote:
> On Fri, Apr 14, 2023 at 11:22:55AM +0300, Adrian Hunter wrote:
>> Hi
>>
>> Here is a stab at adding an ioctl for sideband events.
>>
>> This is to overcome races when reading the same information
>> from /proc.
>
> What races? Are you talking about reading old state in /proc the kernel
> delivering a sideband event for the new state, and then you writing the
> old state out?
>
> Surely that's something perf tool can fix without kernel changes?
Yes, and it was a bit of a brain fart not to realise that.
There may still be corner cases, where different kinds of events are
interdependent, perhaps NAMESPACES events vs MMAP events could
have ordering issues.
Putting that aside, the ioctl may be quicker than reading from
/proc. I could get some numbers and see what people think.
Powered by blists - more mailing lists