From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: Ian Campbell <Ian.Campbell@eu.citrix.com>,
Thomas Gleixner <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
"JBeulich@novell.com" <JBeulich@novell.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>
Subject: Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
Date: Mon, 09 May 2011 11:45:13 +1000 [thread overview]
Message-ID: <4DC74729.9090508@goop.org> (raw)
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1505C8ED7FAA0@shsmsx502.ccr.corp.intel.com>
On 05/09/2011 10:44 AM, Tian, Kevin wrote:
>> It doesn't really need to be an irq. The main reason was so that it would
>> appear in /proc/interrupts so I could use the counter as a "number of times a
>> spinlock was kicked" counter. That could be exposed in some other way if
>> being part of the interrupt infrastructure brings too much baggage with it.
>>
> Perhaps we don't need an irq binding here. Just like a local APIC interrupt
> source which only needs vector. Somehow the virq or vipi concept in Xen
> context is similar.
An event channel is logically equivalent to a vector, so that would make
sense. We currently allocate irqs for cross-cpu call and reschedule
event channels, whereas native x86 simply uses a naked vector for
those. But they are real interrupts, so an irq at least makes some
logical sense in those cases.
For spinlocks, the event channel is more like a usermode-level signal
which is always blocked and only ever tested with sigsuspend (or is it
sigpoll? something like that).
J
WARNING: multiple messages have this Message-ID (diff)
From: Jeremy Fitzhardinge <jeremy@goop.org>
To: "Tian, Kevin" <kevin.tian@intel.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"JBeulich@novell.com" <JBeulich@novell.com>,
Ian Campbell <Ian.Campbell@eu.citrix.com>,
"mingo@redhat.com" <mingo@redhat.com>,
"hpa@zytor.com" <hpa@zytor.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them
Date: Mon, 09 May 2011 11:45:13 +1000 [thread overview]
Message-ID: <4DC74729.9090508@goop.org> (raw)
In-Reply-To: <625BA99ED14B2D499DC4E29D8138F1505C8ED7FAA0@shsmsx502.ccr.corp.intel.com>
On 05/09/2011 10:44 AM, Tian, Kevin wrote:
>> It doesn't really need to be an irq. The main reason was so that it would
>> appear in /proc/interrupts so I could use the counter as a "number of times a
>> spinlock was kicked" counter. That could be exposed in some other way if
>> being part of the interrupt infrastructure brings too much baggage with it.
>>
> Perhaps we don't need an irq binding here. Just like a local APIC interrupt
> source which only needs vector. Somehow the virq or vipi concept in Xen
> context is similar.
An event channel is logically equivalent to a vector, so that would make
sense. We currently allocate irqs for cross-cpu call and reschedule
event channels, whereas native x86 simply uses a naked vector for
those. But they are real interrupts, so an irq at least makes some
logical sense in those cases.
For spinlocks, the event channel is more like a usermode-level signal
which is always blocked and only ever tested with sigsuspend (or is it
sigpoll? something like that).
J
next prev parent reply other threads:[~2011-05-09 1:45 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 6:43 [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them Tian, Kevin
2011-05-06 9:59 ` Thomas Gleixner
2011-05-06 12:54 ` Tian, Kevin
2011-05-06 12:54 ` Tian, Kevin
2011-05-06 13:14 ` [Xen-devel] " Tian, Kevin
2011-05-06 13:24 ` Thomas Gleixner
2011-05-06 14:04 ` Ian Campbell
2011-05-08 1:44 ` Jeremy Fitzhardinge
2011-05-08 1:44 ` Jeremy Fitzhardinge
2011-05-09 0:44 ` Tian, Kevin
2011-05-09 0:44 ` Tian, Kevin
2011-05-09 1:45 ` Jeremy Fitzhardinge [this message]
2011-05-09 1:45 ` Jeremy Fitzhardinge
2011-05-06 14:28 ` Stefano Stabellini
2011-05-06 14:28 ` Stefano Stabellini
2011-05-06 21:43 ` Tian, Kevin
2011-05-09 2:11 ` Tian, Kevin
2011-05-09 12:02 ` Stefano Stabellini
2011-05-09 12:36 ` Thomas Gleixner
2011-05-10 3:24 ` Tian, Kevin
2011-05-18 23:49 ` Tian, Kevin
2011-05-18 23:49 ` Tian, Kevin
2011-05-19 12:08 ` Stefano Stabellini
2011-05-19 16:18 ` [Xen-devel] " Konrad Rzeszutek Wilk
2011-05-19 16:18 ` Konrad Rzeszutek Wilk
2011-08-29 4:15 ` [regression] Ideapad S10-3 does not wake up from suspend (Re: [PATCH v2 2/2] x86: don't unmask disabled irqs when migrating them) Jonathan Nieder
2011-08-31 1:04 ` Dave Hansen
2011-08-31 8:22 ` Jonathan Nieder
2011-09-02 3:01 ` Serge E. Hallyn
2011-09-01 6:24 ` Tian, Kevin
2011-09-01 6:24 ` Tian, Kevin
2012-05-12 23:13 ` [regression] Ideapad S10-3 does not wake up from suspend Jonathan Nieder
2012-05-13 1:22 ` Lars Boegild Thomsen
2012-07-15 23:24 ` Jonathan Nieder
2012-04-15 14:06 ` Jonathan Nieder
2012-04-16 18:05 ` Robert Scott
2012-04-17 2:04 ` Jonathan Nieder
2012-04-18 10:03 ` Lars Boegild Thomsen
2012-04-22 16:34 ` [Xen-devel] " Pasi Kärkkäinen
2012-04-21 13:14 ` Robert Scott
2012-05-06 12:44 ` Robert Scott
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=4DC74729.9090508@goop.org \
--to=jeremy@goop.org \
--cc=Ian.Campbell@eu.citrix.com \
--cc=JBeulich@novell.com \
--cc=hpa@zytor.com \
--cc=kevin.tian@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=xen-devel@lists.xensource.com \
/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.