From: Rusty Russell <rusty@rustcorp.com.au>
To: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>,
"Eric W. Biederman" <ebiederm@xmission.com>,
x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Correct behaviour of irq affinity?
Date: Tue, 24 Mar 2009 23:22:23 +1030 [thread overview]
Message-ID: <200903242322.24943.rusty@rustcorp.com.au> (raw)
In-Reply-To: <86802c440903240021y20abab87j3a780f8a17574716@mail.gmail.com>
On Tuesday 24 March 2009 17:51:43 Yinghai Lu wrote:
> On Mon, Mar 23, 2009 at 10:49 PM, Rusty Russell <rusty@rustcorp.com.au> wrote:
> > The effect of setting desc->affinity (ie. from userspace via sysfs) has varied
> > over time. In 2.6.27, the 32-bit code anded the value with cpu_online_map,
> > and both 32 and 64-bit did that anding whenever a cpu was unplugged.
> >
> > 2.6.29 consolidated this into one routine (and fixed hotplug) but introduced
> > another variation: anding the affinity with cfg->domain. Is this right, or
> > should we just set it to what the user said? Or as now, indicate that we're
> > restricting it.
> >
> > If we should change it, here's what the patch looks like against x86 tip
> > (cpu_mask_to_apicid_and already takes cpu_online_mask into account):
> >
> > diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
> > index 86827d8..30906cd 100644
> > --- a/arch/x86/kernel/apic/io_apic.c
> > +++ b/arch/x86/kernel/apic/io_apic.c
> > @@ -592,10 +592,10 @@ set_desc_affinity(struct irq_desc *desc, const struct cpumask *mask)
> > if (assign_irq_vector(irq, cfg, mask))
> > return BAD_APICID;
> >
> > - cpumask_and(desc->affinity, cfg->domain, mask);
> > + cpumask_copy(desc->affinity, mask);
> > set_extra_move_desc(desc, mask);
> >
> > - return apic->cpu_mask_to_apicid_and(desc->affinity, cpu_online_mask);
> > + return apic->cpu_mask_to_apicid_and(desc->affinity, cfg->domain);
> > }
> >
> > static void
> >
> cfg->domain for logical flat: will be ALL_CPUS
> for phys flat (aka bigsmp on 32bit) will be one cpu set mask.
>
> so desc->affinity: for logical will be not changed, but
> set_desc_affinity() return will be changed. ( not add with
> cpu_online_mask anymore)
No, internally cpu_mask_to_apicid_and() does and with cpu_online_mask
already, eg in include/asm/bigsmp/apic.h:
static inline unsigned int cpu_mask_to_apicid_and(const struct cpumask *cpumask,
const struct cpumask *andmask)
{
int cpu;
/*
* We're using fixed IRQ delivery, can only return one phys APIC ID.
* May as well be the first.
*/
for_each_cpu_and(cpu, cpumask, andmask)
if (cpumask_test_cpu(cpu, cpu_online_mask))
break;
if (cpu < nr_cpu_ids)
return cpu_to_logical_apicid(cpu);
return BAD_APICID;
}
> when mask is 0x0f
> for phys flat, desc->affinity will be changed to 0x0f from
> 0x01/0x02/0x04/08, return set_desc_affinity is not changed.
> so /proc/irq/xx/smp_affinity will be changed. and it does reflect that
> actually affinity.
>
> so this patch looks not right.
Only change should be that smp_affinity will reflect actual affinity, not
affinity user set.
Thanks,
Rusty.
next prev parent reply other threads:[~2009-03-24 12:52 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-24 5:49 [RFC] Correct behaviour of irq affinity? Rusty Russell
2009-03-24 7:21 ` Yinghai Lu
2009-03-24 12:52 ` Rusty Russell [this message]
2009-03-24 20:36 ` Yinghai Lu
2009-03-24 12:39 ` Eric W. Biederman
2009-03-24 19:49 ` Yinghai Lu
2009-03-24 20:23 ` [PATCH] x86: fix set_extra_move_desc calling Yinghai Lu
2009-03-24 21:15 ` [tip:x86/apic] " Yinghai Lu
2009-03-24 21:15 ` [PATCH 1/3] " Yinghai Lu
2009-03-24 21:16 ` [PATCH 2/3] x86: use default_cpu_mask_to_apicid for 64bit Yinghai Lu
2009-03-24 21:30 ` [tip:x86/apic] " Yinghai Lu
2009-03-24 21:34 ` Ingo Molnar
2009-03-24 21:42 ` [PATCH 3/3] x86: Correct behaviour of irq affinity -v2 Yinghai Lu
2009-03-24 21:17 ` [PATCH 3/3] x86: Correct behaviour of irq affinity Yinghai Lu
2009-03-24 21:30 ` [tip:x86/apic] " Rusty Russell
2009-03-25 17:51 ` Rusty Russell
2009-03-25 0:33 ` [RFC] Correct behaviour of irq affinity? Rusty Russell
2009-03-25 0:59 ` Rusty Russell
2009-03-25 1:03 ` 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=200903242322.24943.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=x86@kernel.org \
--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 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.