[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <547CFD93.5000702@linux.intel.com>
Date: Tue, 02 Dec 2014 07:45:23 +0800
From: Jiang Liu <jiang.liu@...ux.intel.com>
To: Bjorn Helgaas <bhelgaas@...gle.com>
CC: Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
"H. Peter Anvin" <hpa@...or.com>,
"Rafael J. Wysocki" <rjw@...ysocki.net>,
Randy Dunlap <rdunlap@...radead.org>,
Yinghai Lu <yinghai@...nel.org>,
Borislav Petkov <bp@...en8.de>,
Jonathan Corbet <corbet@....net>,
"x86@...nel.org" <x86@...nel.org>,
Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Tony Luck <tony.luck@...el.com>,
Joerg Roedel <joro@...tes.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
Daniel J Blueman <daniel@...ascale.com>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>
Subject: Re: [Patch Part3 v4 38/38] x86, irq: Add kernel parameter vector_alloc
to set CPU vector allocation policy
On 2014/12/2 2:49, Bjorn Helgaas wrote:
> On Tue, Nov 25, 2014 at 12:50 AM, Jiang Liu <jiang.liu@...ux.intel.com> wrote:
>> Parameter vector_alloc should be set to an integer with:
>> bit 0: enable allocating CPU vector from CPUs on device local node.
>> That's to allocate from cpumask_of_node(irq_data->node).
>> bit 1: enable the default policy, which is to allocate from
>> apic->target_cpus().
>>
>> When allocating vectors, it tries all enabled policies from lower bit
>> position to higher bit position.
>>
>> This option could be use to optimize interrupt distribution on large
>> system such as NumaChip etc.
>
> Why can't we figure this out automatically? Having a kernel parameter
> is a pain in the neck for users.
Hi Bjorn,
I'm thinking of automatically turning on local vector
allocation if any host bridge has an assigned(valid) NUMA node id.
By this way, user doesn't need to specify the kernel parameter for most
cases. How about this solution?
Thanks!
Gerry
>
>> Signed-off-by: Jiang Liu <jiang.liu@...ux.intel.com>
>> Cc: Daniel J Blueman <daniel@...ascale.com>
>> ---
>> Documentation/kernel-parameters.txt | 6 ++++++
>> arch/x86/kernel/apic/vector.c | 11 +++++++++++
>> 2 files changed, 17 insertions(+)
>>
>> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
>> index 4c81a860cc2b..a175c5016954 100644
>> --- a/Documentation/kernel-parameters.txt
>> +++ b/Documentation/kernel-parameters.txt
>> @@ -3709,6 +3709,12 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
>> vector= [IA-64,SMP]
>> vector=percpu: enable percpu vector domain
>>
>> + vector_alloc= [x86,SMP]
>> + vector_alloc=policy: policy is a bitmap, bit 0
>> + for allocating CPU vector from CPUs on device local
>> + node; bit 1 for the default policy to allocating from
>> + apic->target_cpus(). All higher bits are reserved.
>> +
>> video= [FB] Frame buffer configuration
>> See Documentation/fb/modedb.txt.
>>
>> diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
>> index 16de8906ee1e..1158843551c7 100644
>> --- a/arch/x86/kernel/apic/vector.c
>> +++ b/arch/x86/kernel/apic/vector.c
>> @@ -79,6 +79,17 @@ void set_vector_alloc_policy(unsigned int policy)
>> x86_vector_alloc_policy = policy | X86_VECTOR_POL_CALLER;
>> }
>>
>> +static int __init apic_parse_vector_policy(char *str)
>> +{
>> + int policy;
>> +
>> + if (get_option(&str, &policy) == 1)
>> + set_vector_alloc_policy(policy);
>> +
>> + return 1;
>> +}
>> +__setup("vector_alloc=", apic_parse_vector_policy);
>> +
>> static struct apic_chip_data *alloc_apic_chip_data(int node)
>> {
>> struct apic_chip_data *data;
>> --
>> 1.7.10.4
>>
--
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/
Powered by blists - more mailing lists