linux-kernel - Re: irq 16: nobody cared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130421205139.GC5807@pd.tnic>
Date:	Sun, 21 Apr 2013 22:51:39 +0200
From:	Borislav Petkov <bp@...en8.de>
To:	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Cc:	x86-ml <x86@...nel.org>, lkml <linux-kernel@...r.kernel.org>,
	tiwai@...e.de
Subject: Re: irq 16: nobody cared

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@...e.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.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/