On Tue, 2020-10-06 at 12:35 +0200, Frederic Weisbecker wrote:

On Mon, Oct 05, 2020 at 02:52:49PM -0400, Nitesh Narayan Lal wrote:

quoted

On 10/4/20 7:14 PM, Frederic Weisbecker wrote:

quoted

On Sun, Oct 04, 2020 at 02:44:39PM +0000, Alex Belits wrote:

quoted

The idea behind this is that isolation breaking events are
supposed to
be known to the applications while applications run normally,
and they
should not require any analysis or human intervention to be
handled.

Sure but you can use trace events for that. Just trace
interrupts, workqueues,
timers, syscalls, exceptions and scheduler events and you get all
the local
disturbance. You might want to tune a few filters but that's
pretty much it.

formation,

quoted

quoted

you can trace the workqueue and timer queue events and just
filter those that
target your isolated CPUs.

I agree that we can do all those things with tracing.
However, IMHO having a simplified logging mechanism to gather the
source of
violation may help in reducing the manual effort.

Although, I am not sure how easy will it be to maintain such an
interface
over time.

The thing is: tracing is your simplified logging mechanism here. You
can achieve
the same in userspace with _way_ less code, no race, and you can do
it in
bash.

The idea is that this mechanism should be usable when no one is there
to run things in bash, or no information about what might happen. It
should be able to report rare events in production when users may not
be able to reproduce them.

-- 
Alex