[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1wt2z1qxi.fsf@ebiederm.dsl.xmission.com>
Date: Sat, 03 Feb 2007 03:22:33 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Andi Kleen <ak@...e.de>
Cc: Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org,
"Lu, Yinghai" <yinghai.lu@....com>,
"Luigi Genoni" <luigi.genoni@...elli.com>,
Ingo Molnar <mingo@...e.hu>,
Natalie Protasevich <protasnb@...il.com>
Subject: Re: [PATCH 2/2] x86_64 irq: Handle irqs pending in IRR during irq migration.
Andi Kleen <ak@...e.de> writes:
>> Once the migration operation is complete we know we will receive
>> no more interrupts on this vector so the irq pending state for
>> this irq will no longer be updated. If the irq is not pending and
>> we are in the intermediate state we immediately free the vector,
>> otherwise in we free the vector in do_IRQ when the pending irq
>> arrives.
>
> Ok for me, although the magic numbers are a little nasty.
You must be talking about (vector/32) *0x10.
The 32 is the number of bits and 0x10 the gap between apic
registers. I couldn't think of a better form. If someone
can think of a better way it probably warrants a cleanup patch
at some point.
> What about i386?
i386 does not handle this case but since it is still globally
allocating all of it's vectors and never changes it's vectors during
migration it is totally harmless when an irq comes in on a cpu other
than the one we are expecting it on.
Eric
-
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