All of lore.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: 27+ 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-27  1:05     ` 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 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.