linux-kernel - Re: [GIT PULL tip/genirq] Please pull from lost-spurious-irq

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]

Date:	Mon, 2 Aug 2010 23:51:13 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Tejun Heo <tj@...nel.org>
cc:	lkml <linux-kernel@...r.kernel.org>, Jeff Garzik <jeff@...zik.org>,
	Greg KH <gregkh@...e.de>
Subject: Re: [GIT PULL tip/genirq] Please pull from lost-spurious-irq

Tejun,

On Mon, 2 Aug 2010, Tejun Heo wrote:

> Hello, Thomas.
> 
> On 08/02/2010 08:52 PM, Thomas Gleixner wrote:
> >> Ooh, another reason is timer locality.  If timers are shared per desc,
> >> they have much higher chance of being on the same processor.  Global
> >> timers would be pretty bad in that respect.
> > 
> > That's irrelevant. If you need to poll an interrupt, then it does not
> > matter at all whether you bounce some cache lines or not.
> > 
> > In fact we have two cases:
> > 
> >    1) An interrupt needs to be polled all the time. That sucks whether
> >       the poll timer bounces a few cache lines or not.
> > 
> >    2) Polling an irq for some time. Either it works again after a
> >       while, so your suckage is restricted to the poll period. If not
> >       see #1
> 
> Hmm... for spurious and watch the above are true and if it were the
> above two it would definitely make more sense to use per-purpose
> global timers.  The problem is w/ expect tho.  It's supposed to be
> used with normal hot paths, so expect/unexpect operations better be
> low overhead and local.  I'll talk more about it in the other reply.

No, it's not. You are just looking at it from the wrong
perspective. The expect scenario is just a different form of
watch. You worked around the problem by moving the timer to 3 seconds
+ slack if everything works as expected, but that's just sloppy. In
fact you really want to kick that thing in when things go awry and
take it away when it comes back to normal.  When things go awry, then
the cache line bouncing is the least of your worries, really.

Thanks,

	tglx

--
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/