public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Borislav Petkov <bp@alien8.de>
To: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Cc: x86-ml <x86@kernel.org>, lkml <linux-kernel@vger.kernel.org>,
	tiwai@suse.de
Subject: Re: irq 16: nobody cared
Date: Sun, 21 Apr 2013 22:51:39 +0200	[thread overview]
Message-ID: <20130421205139.GC5807@pd.tnic> (raw)
In-Reply-To: <20130421203447.GE3509@linux.vnet.ibm.com>

On Sun, Apr 21, 2013 at 01:34:47PM -0700, Paul E. McKenney wrote:
> > No warning, no delay, 2 suspend/resume cycles back-to-back. So, a
> > probable fix could be to force-enable the expedited grace periods during
> > suspend...?
> 
> Fix for the slowness, for sure!
> 
> For the irq warning, it is most likely simply hiding the problem.

Hmm, they seem somehow related. The warning doesn't appear when
rcu_expedited is set which means, RCU grace periods are shorter, leading
up to less IRQ 16 interrupts piling up and not hitting the magic 99900
irq count.

At least this is how I primitively imagine it...

Btw this magic number is pretty old:

commit e40419dbdb3b5c912d35f8736c51687bf4e0deb0
Author: Ingo Molnar <mingo@elte.hu>
Date:   Mon Oct 18 08:55:37 2004 -0700

    [PATCH] generic irq subsystem: core

Probably Ingo and tglx know why it was chosen. :)

> Still, speeding up suspend sounds valuable.  The connection between
> suspending and expediting grace periods probably needs to be in
> the kernel -- people will undoubtedly want to expedite them for short
> periods of time at runtime, like when starting wireshark, and it would
> be good to minimize unnecessary dependency on scripting.
> 
> It would not be hard to provide an in-kernel primitive for expediting.

Well, this should be trivial, no? A one-liner setting rcu_expedited
to 1 somewhere at the beginning of suspend. When we go further down,
synchronize_sched() et al will pick up the change.

> Hmmm... When you resume, is the expediting still set? (Can't see why
> it would not be.)

Sure.

> If so, it would be good to have some way of disabling
> it after boot completes.  Which, as noted in another thread, requires
> that RCU be informed of when boot completes.  ;-)

A similar oneliner at the end of the resume path.

Maybe have rcu suspend/resume callbacks where you can do this stuff and
maybe more in the future.

Btw, I have no idea how the suspend and resume paths look like, will
have to dig a bit. Rafael would know though :-)

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

  reply	other threads:[~2013-04-21 20:51 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-20 18:53 irq 16: nobody cared Borislav Petkov
2013-04-20 23:52 ` Paul E. McKenney
2013-04-21 10:34   ` Borislav Petkov
2013-04-21 16:30     ` Paul E. McKenney
2013-04-21 16:56       ` Borislav Petkov
2013-04-21 18:10         ` Borislav Petkov
2013-04-21 18:56           ` Paul E. McKenney
2013-04-21 19:06             ` Borislav Petkov
2013-04-21 20:34               ` Paul E. McKenney
2013-04-21 20:51                 ` Borislav Petkov [this message]
2013-04-21 21:42                   ` Borislav Petkov
2013-04-21 22:00                     ` Paul E. McKenney
2013-04-21 22:12                       ` Borislav Petkov
2013-04-22  8:01                         ` Ingo Molnar
2013-04-22  9:18                           ` Borislav Petkov
2013-04-22 13:16                             ` Paul E. McKenney
2013-04-21 18:47         ` Paul E. McKenney
2013-04-22  8:32       ` Takashi Iwai
2013-04-22  9:13         ` Borislav Petkov
2013-04-22  9:19           ` Takashi Iwai
2013-04-22 10:06             ` Borislav Petkov
2013-04-22 11:33               ` Takashi Iwai
2013-04-22 13:56                 ` Borislav Petkov
2013-04-22 12:56             ` Thomas Gleixner
2013-04-22 14:23               ` Borislav Petkov
2013-04-22 14:44                 ` Paul E. McKenney
2013-04-22 21:33                   ` Borislav Petkov
2013-04-22 22:07                     ` Paul E. McKenney
2013-04-23 14:10                     ` Thomas Gleixner
2013-04-23 14:34                       ` Borislav Petkov
2013-04-23 15:01                       ` Paul E. McKenney

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=20130421205139.GC5807@pd.tnic \
    --to=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=tiwai@suse.de \
    --cc=x86@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