public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <teheo@suse.de>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Jeff Garzik <jeff@garzik.org>, Greg KH <gregkh@suse.de>
Subject: Re: [GIT PULL tip/genirq] Please pull from lost-spurious-irq
Date: Mon, 02 Aug 2010 21:57:27 +0200	[thread overview]
Message-ID: <4C572327.7040801@suse.de> (raw)
In-Reply-To: <alpine.LFD.2.00.1008022022560.27107@localhost.localdomain>

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.

> And it's even less of an issue as the main users of this misfeature
> are laptops and desktop machines, where locality is not really that
> important. If an enterprise admin decides to ignore the fact that the
> hardware is flaky, then he does not care about the cache line bounces
> either.

These problems do happen on intel chipset machines and is something
which can be worked around with some effort.  Eh, let's talk on the
other reply.

Thanks.

-- 
tejun

  reply	other threads:[~2010-08-02 20:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-28 13:42 [GIT PULL tip/genirq] Please pull from lost-spurious-irq Tejun Heo
2010-07-28 13:46 ` Tejun Heo
2010-07-29  8:44   ` Thomas Gleixner
2010-07-30  9:46     ` Tejun Heo
2010-08-02 14:07       ` Thomas Gleixner
2010-08-02 15:28         ` Tejun Heo
2010-08-02 15:35           ` Tejun Heo
2010-08-02 18:52             ` Thomas Gleixner
2010-08-02 19:57               ` Tejun Heo [this message]
2010-08-03 10:06                 ` Thomas Gleixner
2010-08-03 10:15                   ` Tejun Heo
2010-08-02 21:06               ` Tejun Heo
2010-08-02 21:51                 ` Thomas Gleixner
2010-08-02 17:10           ` Thomas Gleixner
2010-08-02 20:48             ` Tejun Heo
2010-08-02 22:28               ` Thomas Gleixner
2010-08-03  8:49                 ` Tejun Heo
2010-08-03 11:43                   ` 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=4C572327.7040801@suse.de \
    --to=teheo@suse.de \
    --cc=gregkh@suse.de \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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