All of lore.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Paul McKenney <paulmck@kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Subject: Re: [patch V2 2/9] irqtime: Make accounting correct on RT
Date: Mon, 7 Dec 2020 02:14:48 +0100	[thread overview]
Message-ID: <20201207011448.GC113660@lothringen> (raw)
In-Reply-To: <87czzm77re.fsf@nanos.tec.linutronix.de>

On Mon, Dec 07, 2020 at 01:57:25AM +0100, Thomas Gleixner wrote:
> On Mon, Dec 07 2020 at 01:23, Frederic Weisbecker wrote:
> >> --- a/kernel/sched/cputime.c
> >> +++ b/kernel/sched/cputime.c
> >> @@ -60,7 +60,7 @@ void irqtime_account_irq(struct task_str
> >>  	cpu = smp_processor_id();
> >>  	delta = sched_clock_cpu(cpu) - irqtime->irq_start_time;
> >>  	irqtime->irq_start_time += delta;
> >> -	pc = preempt_count() - offset;
> >> +	pc = irq_count() - offset;
> >
> > There are many preempt_count() users all around waiting for similar issues.
> > Wouldn't it be more reasonable to have current->softirq_disable_cnt just saving
> > the softirq count on context switch?
> 
> There are not that many and all of them need to be looked at.
> 
> > diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> > index d2003a7d5ab5..6c899c35d6ba 100644
> > --- a/kernel/sched/core.c
> > +++ b/kernel/sched/core.c
> > @@ -3469,6 +3469,10 @@ static inline void prepare_task(struct task_struct *next)
> >  
> >  static inline void finish_task(struct task_struct *prev)
> >  {
> > +#ifdef CONFIG_PREEMPT_RT
> > +	prev->softirq_disable_cnt = softirq_count();
> > +	__preempt_count_sub(prev->softirq_disable_cnt);
> > +#endif
> 
> You fundamentaly break RT with that.
> 
> If local_bh_disable() fiddles with the actual preempt_count on RT then
> softirq disabled sections and softirq processing are not longer
> preemtible.
> 
> You asked me in the last round of patches to add a proper argument for
> pulling out the softirq count from preempt_count. Here is the revised
> changelog which you agreed with:
> 
>  "RT requires the softirq processing and local bottomhalf disabled regions to
>   be preemptible. Using the normal preempt count based serialization is
>   therefore not possible because this implicitely disables preemption.
>   ....
>  "
> 
> Full text in patch 1/9.
> 
> According to the above folding of softirq count into the actual preempt
> count cannot work at all.
> 
> The current RT approach just works except for the places which look at
> the raw preempt_count and not using the wrappers. Those places are
> restricted to core code and a pretty small number.
> 
> Trying to do what you suggest would be a major surgery all over the
> place including a complete trainwreck on the highly optimized
> preempt_enable() --> preempt decision.

I suspected it was more complicated than I imagined :-)
Nevermind.

Thanks.

  reply	other threads:[~2020-12-07  1:15 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-04 17:01 [patch V2 0/9] softirq: Make it RT aware Thomas Gleixner
2020-12-04 17:01 ` [patch V2 1/9] softirq: Add RT specific softirq accounting Thomas Gleixner
2020-12-07 13:06   ` Frederic Weisbecker
2020-12-04 17:01 ` [patch V2 2/9] irqtime: Make accounting correct on RT Thomas Gleixner
2020-12-07  0:23   ` Frederic Weisbecker
2020-12-07  0:57     ` Thomas Gleixner
2020-12-07  1:14       ` Frederic Weisbecker [this message]
2020-12-07 13:27   ` Frederic Weisbecker
2020-12-07 14:44     ` Thomas Gleixner
2020-12-04 17:01 ` [patch V2 3/9] softirq: Move various protections into inline helpers Thomas Gleixner
2020-12-07 13:37   ` Frederic Weisbecker
2020-12-04 17:01 ` [patch V2 4/9] softirq: Make softirq control and processing RT aware Thomas Gleixner
2020-12-07 14:16   ` Frederic Weisbecker
2020-12-07 15:08     ` Thomas Gleixner
2020-12-08  0:08   ` Frederic Weisbecker
2020-12-09 10:11   ` Peter Zijlstra
2020-12-09 12:36     ` Thomas Gleixner
2020-12-09 12:42       ` Peter Zijlstra
2020-12-09 13:30         ` Thomas Gleixner
2020-12-09 10:34   ` Peter Zijlstra
2020-12-04 17:01 ` [patch V2 5/9] tick/sched: Prevent false positive softirq pending warnings on RT Thomas Gleixner
2020-12-08 12:23   ` Frederic Weisbecker
2020-12-04 17:01 ` [patch V2 6/9] rcu: Prevent false positive softirq warning " Thomas Gleixner
2020-12-04 17:59   ` Paul E. McKenney
2020-12-04 17:01 ` [patch V2 7/9] softirq: Replace barrier() with cpu_relax() in tasklet_unlock_wait() Thomas Gleixner
2020-12-07 11:39   ` Peter Zijlstra
2020-12-07 15:21     ` Thomas Gleixner
2020-12-04 17:01 ` [patch V2 8/9] tasklets: Use static inlines for stub implementations Thomas Gleixner
2020-12-04 17:02 ` [patch V2 9/9] tasklets: Prevent kill/unlock_wait deadlock on RT Thomas Gleixner
2020-12-07 11:47   ` Peter Zijlstra
2020-12-07 14:00     ` Sebastian Andrzej Siewior
2020-12-07 14:27       ` Peter Zijlstra
2020-12-07 17:55         ` Thomas Gleixner
2020-12-07 15:22       ` Thomas Gleixner
2020-12-07 15:39         ` Sebastian Andrzej Siewior
2020-12-07 17:49           ` Thomas Gleixner
2020-12-07 17:50             ` Thomas Gleixner
2020-12-06 10:05 ` [patch V2 0/9] softirq: Make it RT aware Sebastian Andrzej Siewior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201207011448.GC113660@lothringen \
    --to=frederic@kernel.org \
    --cc=bigeasy@linutronix.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.