From: Ian Campbell <ijc@hellion.org.uk>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Yinghai Lu <yinghai@kernel.org>,
mingo@redhat.com, hpa@zytor.com, linux-kernel@vger.kernel.org,
tglx@linutronix.de, mingo@elte.hu,
linux-tip-commits@vger.kernel.org,
Jeremy Fitzhardinge <jeremy@goop.org>
Subject: Re: [tip:x86/irq] x86: apic: Fix mismerge, add arch_probe_nr_irqs() again
Date: Mon, 01 Mar 2010 21:44:20 +0000 [thread overview]
Message-ID: <1267479860.2785.843.camel@localhost.localdomain> (raw)
In-Reply-To: <m1d3zn7uwl.fsf@fess.ebiederm.org>
[-- Attachment #1: Type: text/plain, Size: 1148 bytes --]
On Mon, 2010-03-01 at 10:34 -0800, Eric W. Biederman wrote:
>
> As of 2.6.33 the limitations in DomU support are:
> - xen_evtchn_do_upcall starts with the irq number instead of
> the irq_desc, and happens to unnecessarily call into arch
> specific code.
I saw a patch to fix this one recently, "xen: Remove unnecessary arch
specific xen irq functions.", right?
> - Xen has an array irq_info[NR_IRQS] one of the last static arrays
> sized at NR_IRQs in the entire kernel.
Hopefully the same info as is in that array could (and indeed should) be
instead stored in irq_desc->chip_data. Would you object to
arch_init_copy_chip_data and arch_free_chip_data becoming function
pointers within the struct irq_chip?
> If you can fix the Xen code so it isn't dragging the rest of the
> kernel down when it comes to large numbers of irqs more power to you.
If you know of other aspects of the Xen code where this is the case (or
find them in the future) please let me know, I'll do my best to fix
them.
Ian.
--
Ian Campbell
To the systems programmer, users and applications serve only to provide a
test load.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
next prev parent reply other threads:[~2010-03-01 21:44 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-03 3:31 x86: fix race in create_irq_nr on irq_desc Brandon Philips
2010-02-03 10:20 ` Yinghai Lu
2010-02-03 17:42 ` Brandon Philips
2010-02-03 19:31 ` Yinghai Lu
2010-02-04 3:17 ` Brandon Philips
2010-02-05 8:45 ` [PATCH] x86: keep chip_data in create_irq_nr Yinghai Lu
2010-02-05 21:05 ` Brandon Philips
2010-02-05 21:42 ` H. Peter Anvin
2010-02-05 21:09 ` [PATCH] x86: keep chip_data in create_irq_nr and destroy_irq Brandon Philips
2010-02-05 22:44 ` Yinghai Lu
2010-02-05 22:55 ` Brandon Philips
2010-02-06 0:06 ` Yinghai Lu
2010-02-06 0:18 ` [PATCH v2] " Brandon Philips
2010-02-06 6:42 ` [PATCH v3] " Brandon Philips
2010-02-06 7:16 ` Yinghai Lu
2010-02-06 20:05 ` Brandon Philips
2010-02-07 21:02 ` [PATCH v4] " Brandon Philips
2010-02-19 6:06 ` [tip:x86/urgent] x86, irq: Keep " tip-bot for Brandon Philips
2010-02-26 10:26 ` [tip:x86/irq] x86: apic: Fix mismerge, add arch_probe_nr_irqs() again tip-bot for Ingo Molnar
2010-02-26 18:19 ` Yinghai Lu
2010-02-27 9:10 ` Ingo Molnar
2010-02-27 9:37 ` Eric W. Biederman
2010-02-27 9:53 ` Ingo Molnar
2010-02-27 10:12 ` Eric W. Biederman
2010-03-01 11:22 ` Ian Campbell
2010-03-01 18:34 ` Eric W. Biederman
2010-03-01 21:44 ` Ian Campbell [this message]
2010-03-01 21:58 ` Eric W. Biederman
2010-03-02 8:31 ` Thomas Gleixner
2010-03-10 10:55 ` Ian Campbell
2010-03-10 10:55 ` [PATCH] x86: namespace some I/O APIC related structures and functions ijc
2010-03-10 17:07 ` Eric W. Biederman
2010-03-10 10:55 ` [PATCH] irq: move some interrupt arch_* functions into struct irq_chip ijc
2010-03-10 11:00 ` Ian Campbell
2010-03-10 17:18 ` Eric W. Biederman
2010-03-10 17:41 ` Ian Campbell
2010-03-10 18:11 ` Eric W. Biederman
2010-03-10 12:06 ` Yinghai Lu
2010-03-10 12:51 ` Ian Campbell
2010-03-10 17:42 ` Eric W. Biederman
2010-03-10 17:50 ` Ian Campbell
2010-03-10 18:15 ` Eric W. Biederman
2010-03-10 18:28 ` Ian Campbell
2010-03-10 18:27 ` Jeremy Fitzhardinge
2010-03-10 18:59 ` Yinghai Lu
2010-03-10 19:15 ` Eric W. Biederman
2010-03-10 22:07 ` Michael Ellerman
2010-03-10 10:55 ` [PATCH] x86: irq_desc->chip_data is always correct whether or not SPARSE_IRQ is enabled ijc
2010-03-01 22:01 ` [tip:x86/irq] x86: apic: Fix mismerge, add arch_probe_nr_irqs() again Jeremy Fitzhardinge
2010-02-27 12:57 ` [tip:x86/apic] " tip-bot for Ingo Molnar
2010-02-03 10:32 ` x86: fix race in create_irq_nr on irq_desc Yinghai Lu
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=1267479860.2785.843.camel@localhost.localdomain \
--to=ijc@hellion.org.uk \
--cc=ebiederm@xmission.com \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=yinghai@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;
as well as URLs for NNTP newsgroup(s).