Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote on 16.10.2007
11:01:49:
>
>
> Christoph, have any of you tried it on powerpc ?
No we didn't try this (yet).
This approach makes a lot of sense.
Why is this not installed by both large distros on PPC by default?
how mature is this for larger SMPs
Hi,
> As far as I know, the x86 in-kernel thingy doesn't but yeah, the
> userland one seems much more evolved and does things based on the
> "class" of the device.
>
> Christoph, have any of you tried it on powerpc ?
FYI It works fine on PowerPC and its installed by default on some
distros (eg
David Miller wrote:
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 18:28:56 +1000
Allright, so that's an out of tree userland thingy... (which may well
work on ppc too I suppose). Definitely not installed by default by my
distro so IRQs from the network cards on all x86
On Tue, 2007-10-16 at 01:31 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 18:28:56 +1000
>
> > Allright, so that's an out of tree userland thingy... (which may well
> > work on ppc too I suppose). Definitely not installed by default by my
>
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 18:28:56 +1000
> Allright, so that's an out of tree userland thingy... (which may well
> work on ppc too I suppose). Definitely not installed by default by my
> distro so IRQs from the network cards on all x86's using ubuntu g
On Tue, 2007-10-16 at 00:44 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Tue, 16 Oct 2007 17:29:47 +1000
>
> > Do you have any pointer to how that is done on x86 or sparc64 ?
>
> Sparc64 does it statically in the kernel.
>
> For x86, see http://irqbalanc
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Tue, 16 Oct 2007 17:29:47 +1000
> Do you have any pointer to how that is done on x86 or sparc64 ?
Sparc64 does it statically in the kernel.
For x86, see http://irqbalance.org/
-
To unsubscribe from this list: send the line "unsubscribe netde
> So the powerpc platform just honors the affinity mask, and depending on
> the PIC does things that range from nothing to spreading interrupts to
> CPUs in the affinity mask.
>
> All interrupts by defaults are spread to all CPUs (full balancing).
>
> At this stage, it's afaik userland business t
Jumping on an old train ...
On Wed, 2007-09-12 at 05:50 -0700, David Miller wrote:
>
> > This would mean we have a problem on all SMP machines right now.
>
> This is not a correct statement.
>
> Only on your platform do network device interrupts get moved
> around, no other platform does this.
On Wednesday 19 September 2007 17:33, Roland Dreier wrote:
> > One other thing I observed is that I can not unload the module as the
> > ref counter of the eth device is too low. I haven't tracked down the
> > source of this problem yet.
>
> I suspect that this is because netif_rx_reschedule()
> One other thing I observed is that I can not unload the module as the
> ref counter of the eth device is too low. I haven't tracked down the
> source of this problem yet.
I suspect that this is because netif_rx_reschedule() was missing a
dev_hold() to match the dev_put() in netif_rx_complete
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Tue, 18 Sep 2007 18:15:45 +0200
> One other thing I observed is that I can not unload the module as the
> ref counter of the eth device is too low. I haven't tracked down the
> source of this problem yet.
This is probably because of the resched d
Hi,
On Saturday 15 September 2007 00:12, David Miller wrote:
> Ok, for now I'm going to try and deal with this by reverting
> the list handling to something approximating the old NAPI
> code, as per the patch below.
>
> I've only quickly test booted into this kernel on my workstation.
> So take c
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 7 Sep 2007 11:37:02 +0200
> Its about the question who inserts and removes devices from the poll list.
>
> netif_rx_schedule: sets NAPI_STATE_SCHED flag, insert device in poll list.
> netif_rx_complete: clears NAPI_STATE_SCHED
> netif_rx_resc
On Wednesday 12 September 2007, Christoph Raisch wrote:
> David Miller <[EMAIL PROTECTED]> wrote on 12.09.2007 14:50:04:
>
> > I agree that it should be fixed, but we should also fix the IRQ
> > distribution scheme used on powerpc platforms which is totally
> > broken in these cases.
>
> This is d
From: Christoph Raisch <[EMAIL PROTECTED]>
Date: Wed, 12 Sep 2007 15:10:08 +0200
> This is definitely not something we can change in the HEA device driver
> alone.
And it shouldn't be, x86 implements the policy in irq balance
daemon, powerpc should do it wherever it would be appropriate
there.
>
David Miller <[EMAIL PROTECTED]> wrote on 12.09.2007 14:50:04:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> Date: Fri, 7 Sep 2007 11:37:02 +0200
>
> > 2) On SMP systems: after netif_rx_complete has been called on CPU1
> >(+interruts enabled), netif_rx_schedule could be called on CPU2
> >
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 7 Sep 2007 11:37:02 +0200
> 2) On SMP systems: after netif_rx_complete has been called on CPU1
>(+interruts enabled), netif_rx_schedule could be called on CPU2
>(irq handler) before net_rx_action on CPU1 has checked NAPI_STATE_SCHED.
Hi Stephen,
I saw that you developed most of the new NAPI interface.
I already addressed this issue a while ago. Please correct me if I got
it wrong. I think there is still a serious problem with the NAPI
changes to make NAPI polling independent of struct net_device objects.
Its about the question
19 matches
Mail list logo
