Thread (11 messages) flat view 11 messages, 2 authors, 2025-07-16

Re: [PATCH v3 12/17] sched: Adapt sched tracepoints for RV task model

From: Gabriele Monaco <gmonaco@redhat.com>
Date: 2025-07-16 16:14:47
Also in: lkml

On Wed, 2025-07-16 at 17:31 +0200, Peter Zijlstra wrote:
On Wed, Jul 16, 2025 at 04:38:36PM +0200, Gabriele Monaco wrote:
quoted
So as you said, we can still reconstruct what happened from the
trace, but the model suddenly needs more states and more events.
So given a sequence like:

  trace_sched_enter_tp();
  { trace_irq_disable();
    **irq_entry();**
    **irq_exit();**
    trace_irq_enable(); } * Ni
  trace_irq_disable();
  { trace_sched_switch(); } * Nj
  trace_irq_enable();
  { trace_irq_disable();
    **irq_entry();**
    **irq_exit();**
    trace_irq_enable(); } * Nk
  trace_sched_exit_tp();

It becomes somewhat hard to figure out which exact IRQ disabled
section
the switch did not happen in (Nj == 0).
quoted
If we could directly tell whether interrupts were disabled manually
or from an actual interrupt, that wouldn't be necessary, for
instance (as in the original model by Daniel).
Hmm.. we do indeed appear to trace the IRQ state before adding
HARDIRQ_OFFSET to preempt_count(). Yes, that complicates things a
little.

So... it *might* be possible to lift lockdep_hardirq_enter() to
before we start tracing. But then you're stuck to running with
lockdep enabled -- I'm thinking that's not ideal, given those other
patches you sent.

I'm going to go on holidays soon, but I've made a note to see if we
can lift setting HARDIRQ_OFFSET before we start tracing. IIRC the
current order is because setting HARDIRQ_OFFSET is using
preempt_count_add() which can be instrumented itself.
Yeah I wondered if that was something perhaps required by RCU or
something else (some calls are in the way). NMIs have it set during the
tracepoints, for instance.

Thanks again and enjoy your holiday!

Gabriele
But we could use __preempt_count_add() instead, then we loose the
tracing from setting HARDIRQ_OFFSET, but I don't think that is a
problem. We already get the latency from the IRQ tracepoints after
all.
quoted
I get your point why we don't really need the additional
tracepoint, but some
arguments giving more context come almost for free.
Right. So please always try and justify adding tracepoints.
  
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help