public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <frederic@kernel.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: qianjun.kernel@gmail.com, peterz@infradead.org, will@kernel.org,
	luto@kernel.org, linux-kernel@vger.kernel.org,
	laoar.shao@gmail.com, qais.yousef@arm.com, urezki@gmail.com
Subject: Re: [PATCH V7 4/4] softirq: Allow early break the softirq processing loop
Date: Sat, 26 Sep 2020 14:22:20 +0200	[thread overview]
Message-ID: <20200926122220.GA10735@lenoir> (raw)
In-Reply-To: <874knlv5pq.fsf@nanos.tec.linutronix.de>

On Sat, Sep 26, 2020 at 12:42:25AM +0200, Thomas Gleixner wrote:
> On Fri, Sep 25 2020 at 02:42, Frederic Weisbecker wrote:
> 
> > On Thu, Sep 24, 2020 at 05:37:42PM +0200, Thomas Gleixner wrote:
> >> Subject: softirq; Prevent starvation of higher softirq vectors
> > [...]
> >> +	/*
> >> +	 * Word swap pending to move the not yet handled bits of the previous
> >> +	 * run first and then clear the duplicates in the newly raised ones.
> >> +	 */
> >> +	swahw32s(&cur_pending);
> >> +	pending = cur_pending & ~(cur_pending << SIRQ_PREV_SHIFT);
> >> +
> >>  	for_each_set_bit(vec_nr, &pending, NR_SOFTIRQS) {
> >>  		int prev_count;
> >>  
> >> +		vec_nr &= SIRQ_VECTOR_MASK;
> >
> > Shouldn't NR_SOFTIRQS above protect from that?
> 
> It does, but that's wrong. The bitmap size in that for_each() loop must
> obviously be SIRQ_PREV_SHIFT + NR_SOFTIRQS for this to work.

Ah! I see, I thought you were ignoring the high bits on
purpose, hence my questions after about pending.

> 
> >> +	} else {
> >> +		/*
> >> +		 * Retain the unprocessed bits and swap @cur_pending back
> >> +		 * into normal ordering
> >> +		 */
> >> +		cur_pending = (u32)pending;
> >> +		swahw32s(&cur_pending);
> >> +		/*
> >> +		 * If the previous bits are done move the low word of
> >> +		 * @pending into the high word so it's processed first.
> >> +		 */
> >> +		if (!(cur_pending & SIRQ_PREV_MASK))
> >> +			cur_pending <<= SIRQ_PREV_SHIFT;
> >
> > If the previous bits are done and there is no timeout, should
> > we consider to restart a loop?
> 
> We only enter this code path if there was a timeout. Otherwise pending
> would be 0.

Right with SIRQ_PREV_SHIFT + NR_SOFTIRQS now that whole makes sense!

Thanks!

  reply	other threads:[~2020-09-26 12:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 11:56 [PATCH V7 0/4] Softirq:avoid large sched delay from the pending softirqs qianjun.kernel
2020-09-15 11:56 ` [PATCH V7 1/4] softirq: Use sched_clock() based timeout qianjun.kernel
2020-09-24  8:34   ` Thomas Gleixner
2020-09-15 11:56 ` [PATCH V7 2/4] softirq: Factor loop termination condition qianjun.kernel
2020-09-24  8:36   ` Thomas Gleixner
2020-09-24 12:31     ` Thomas Gleixner
2020-09-15 11:56 ` [PATCH V7 3/4] softirq: Rewrite softirq processing loop qianjun.kernel
2020-09-15 11:56 ` [PATCH V7 4/4] softirq: Allow early break the " qianjun.kernel
2020-09-24 15:37   ` Thomas Gleixner
2020-09-24 23:08     ` Frederic Weisbecker
2020-09-24 23:10       ` Frederic Weisbecker
2020-09-25 22:37       ` Thomas Gleixner
2020-09-25  0:42     ` Frederic Weisbecker
2020-09-25 22:42       ` Thomas Gleixner
2020-09-26 12:22         ` Frederic Weisbecker [this message]
2020-09-28 10:51       ` jun qian
2020-09-29 11:44         ` Frederic Weisbecker
2020-10-09 15:01           ` Qais Yousef
2020-10-13 10:43             ` Frederic Weisbecker
2020-10-13 12:40               ` Qais Yousef
2020-09-26  2:00     ` jun qian
2020-09-27  1:05   ` [softirq] 56c21abbe6: will-it-scale.per_process_ops -9.1% regression kernel test robot
2020-09-28  9:20   ` [PATCH V7 4/4] softirq: Allow early break the softirq processing loop Peter Zijlstra
2020-09-28 11:15     ` jun qian
2020-09-28  9:22   ` Peter Zijlstra
2020-09-28 10:09     ` Thomas Gleixner

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=20200926122220.GA10735@lenoir \
    --to=frederic@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=peterz@infradead.org \
    --cc=qais.yousef@arm.com \
    --cc=qianjun.kernel@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=urezki@gmail.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox