From: Alex Nixon <alex.nixon@citrix.com>
To: Yinghai Lu <yhlu.kernel@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Jeremy Fitzhardinge <Jeremy.Fitzhardinge@citrix.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] X86: Change the default value of nr_irqs from 32 to NR_IRQs
Date: Tue, 19 Aug 2008 20:50:50 +0100 [thread overview]
Message-ID: <48AB241A.4030706@citrix.com> (raw)
In-Reply-To: <86802c440808191200u364ffd86h49af661e58d20ea3@mail.gmail.com>
Yinghai Lu wrote:
> On Tue, Aug 19, 2008 at 11:32 AM, Alex Nixon <alex.nixon@citrix.com> wrote:
>> Yinghai Lu wrote:
>>> On Tue, Aug 19, 2008 at 11:13 AM, Alex Nixon (Intern)
>>> <Alex.Nixon@citrix.com> wrote:
>>>> Yinghai Lu <yhlu.kernel@gmail.com> wrote:
>>>>> On Tue, Aug 19, 2008 at 9:55 AM, Alex Nixon <alex.nixon@citrix.com>
>>>>> wrote:
>>>>>> If the number of discovered IRQs is suspiciously low, this patch causes
>>>>>> the number reported to default to NR_IRQS, rather than 32. NR_IRQS has
>>>>>> already been defined to be a >sensible value for the current system (in
>>>>>> particular, at least 224 when paravirtualisation is involved).
>>>>>>
>>>>> if only one ioapic, nr will be 24<<1, you will get 48. Does pv has io
>>>>> apic
>>>>> ?
>>>>>
>>>>> YH
>>>>>
>>>> I'm not sure about the general case, but Xen does not (Jeremy correct me
>>>> if
>>>> I'm wrong).
>>>>
>>>> Unless I'm missing something (which I may well be; I'm new to this area
>>>> of
>>>> code), it seems more logical anyway to default back to the calculated
>>>> system-specific value (NR_IRQS), instead of 32, which seems rather
>>>> arbitrary.
>>> can you try !CONFIG_HAVE_SPARSE_IRQ and CONFIG_HAVE_SPARSE_IRQ ?
>>>
>>> YH
>> Sorry I should have mentioned originally - the bug occurs both with
>> CONFIG_HAVE_SPARSE_IRQ enabled, and disabled.
>
> maybe we need special probe_nr_irqs for PV or not call that in
> setup_arch for xen -- it will leave nr_irqs == NR_IRQS
>
> YH
That would be one solution, but would be more involved than this trivial
patch (although if considered more 'correct' then it is of course worth
the effort).
But attempting to keep things simple, is there a reason it's
preferable to fall back to 32 rather NR_IRQS?
- Alex
next prev parent reply other threads:[~2008-08-19 19:51 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-08-19 16:55 [PATCH] X86: Change the default value of nr_irqs from 32 to NR_IRQs Alex Nixon
2008-08-19 17:44 ` Yinghai Lu
[not found] ` <0E902970173AF84089673FA54B7FE78A2CA11D@lonpexch01.citrite.net>
2008-08-19 18:24 ` Yinghai Lu
2008-08-19 18:32 ` Alex Nixon
2008-08-19 19:00 ` Yinghai Lu
2008-08-19 19:50 ` Alex Nixon [this message]
2008-08-19 20:52 ` Yinghai Lu
2008-08-19 23:19 ` Alex Nixon
2008-08-20 23:23 ` Alex Nixon
2008-08-20 23:47 ` Yinghai Lu
2008-08-21 23:21 ` Jeremy Fitzhardinge
2008-08-20 23:23 ` Jeremy Fitzhardinge
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=48AB241A.4030706@citrix.com \
--to=alex.nixon@citrix.com \
--cc=Jeremy.Fitzhardinge@citrix.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=yhlu.kernel@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox