Zwane Mwaikambo wrote:
>
> On Mon, 11 Jul 2005, Oleg Nesterov wrote:
>
> > Please note that entry.S:BUILD_INTERRUPT() also does this trick:
> > pushl $nr-256;
> >
> > so it should be changed as well.
>
> I was making these changes and noticed that those were for the various SMP
> interrupt
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> Oleg Nesterov wrote:
> >
> > Probably it makes sense to change it to
> > pushl $vector - 0x - 1
> >
>
> Please note that entry.S:BUILD_INTERRUPT() also does this trick:
> pushl $nr-256;
>
> so it should be changed as well.
I was ma
Hello Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> Zwane Mwaikambo wrote:
> >
> > --- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43
> > - 1.1.1.1
> > +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37
> > -
> > -
> > +/* Build the I
On Mon, 2005-07-11 at 08:09 -0600, Zwane Mwaikambo wrote:
> On Mon, 11 Jul 2005, Arjan van de Ven wrote:
>
> > On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
> > > Why per node? Why not go the whole way and make it per CPU?
> >
> > Agreed, for two reasons even
> > 1) Per cpu allows for even
Hi,
Agreed, the first version was a per cpu one simply so that i could test it
on a normal SMP system. Andi seems to be of the same opinion, what do you
think of the hotplug cpu case (explained in previous email)?
I think we need to migrate interrupts to the other CPU
in the hotplug CPU case.
> Yes you're right, i wasn't quite awake when i replied, thanks for
> correcting that.
You would need to allocate it using vmalloc if you wanted
to put it node local, eating up precious TLB entries.
Anyways, i386 NUMA is so broken anyways regarding all that that I wouldn't
worry about node local
On Mon, 11 Jul 2005, Brian Gerst wrote:
> Zwane Mwaikambo wrote:
> > On Sun, 11 Jul 2005, Andi Kleen wrote:
> >
> >
> > > Why per node? Why not go the whole way and make it per CPU?
> > >
> > > I would also not define it statically, but allocate it at boot time
> > > in node local memory.
> >
Oleg Nesterov wrote:
>
> Probably it makes sense to change it to
> pushl $vector - 0x - 1
>
Please note that entry.S:BUILD_INTERRUPT() also does this trick:
pushl $nr-256;
so it should be changed as well.
Oleg.
-
To unsubscribe from this list: send the line "unsubscribe lin
Hi Oleg,
On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> > The change is so that we can send IRQs higher than 256 to do_IRQ. That
> > looks like it tries to check if we came in via system_call since we'd save
> > the system call number as orig_eax. Now that i think about it, doesn't
> > that path
Zwane Mwaikambo wrote:
On Sun, 11 Jul 2005, Andi Kleen wrote:
Why per node? Why not go the whole way and make it per CPU?
I would also not define it statically, but allocate it at boot time
in node local memory.
I went per node so that it would be minimal/zero impact for the no-node
case,
Hello Zwane,
Zwane Mwaikambo wrote:
>
> > On Mon, 11 Jul 2005, Oleg Nesterov wrote:
> >
> > Could you explain this change? I think it breaks do_signal/handle_signal,
> > they check orig_eax >= 0 to handle -ERESTARTSYS:
> >
> > /* Are we from a system call? */
> > if (regs->orig_eax >= 0) {
On Mon, 11 Jul 2005, Arjan van de Ven wrote:
> On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
> > Why per node? Why not go the whole way and make it per CPU?
>
> Agreed, for two reasons even
> 1) Per cpu allows for even more devices and cache locality
> 2) While few people have a NUMA syste
On Sun, 11 Jul 2005, Andi Kleen wrote:
> Why per node? Why not go the whole way and make it per CPU?
>
> I would also not define it statically, but allocate it at boot time
> in node local memory.
I went per node so that it would be minimal/zero impact for the no-node
case, it would also simpli
Zwane Mwaikambo wrote:
>
> --- linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 3 Jul 2005 13:20:43
> - 1.1.1.1
> +++ linux-2.6.13-rc1-mm1/arch/i386/kernel/entry.S 10 Jul 2005 22:33:37
> -
> -
> +/* Build the IRQ entry stubs */
> vector=0
> -ENTRY(irq_entries_start)
> + .a
> > I would also not define it statically, but allocate it at boot time
> > in node local memory.
>
> this is probably more tricky so I would suggest doing this in a second
> step.
Not sure it's that tricky. Otherwise he'll waste a lot of memory.
-Andi
-
To unsubscribe from this list: send the
On Mon, 2005-07-11 at 03:59 +0200, Andi Kleen wrote:
> Why per node? Why not go the whole way and make it per CPU?
Agreed, for two reasons even
1) Per cpu allows for even more devices and cache locality
2) While few people have a NUMA system, many have an SMP system so you
get a lot more testing.
Why per node? Why not go the whole way and make it per CPU?
I would also not define it statically, but allocate it at boot time
in node local memory.
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info
As most are aware there is a growing need for more devices on i386/x86_64
based platforms and with that, support for interrupt servicing for all
these devices. The proliferation of MSI based devices will also drive that
requirement higher due to some devices requiring multiple vectors. Natalie
18 matches
Mail list logo
