[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1167230668.3807.37.camel@localhost>
Date: Wed, 27 Dec 2006 09:44:28 -0500
From: jamal <hadi@...erus.ca>
To: Arjan van de Ven <arjan@...radead.org>
Cc: Robert Iakobashvili <coroberti@...il.com>, netdev@...r.kernel.org
Subject: Re: Network card IRQ balancing with Intel 5000 series chipsets
On Wed, 2006-27-12 at 14:08 +0100, Arjan van de Ven wrote:
> sure; however the kernel doesn't provide more accurate information
> currently (and I doubt it could even, it's not so easy to figure out
> which interface triggered the softirq if 2 interfaces share the cpu, and
> then, how much work came from which etc).
>
If you sample CPU use and in between two samples you are able to know
which nic is tied to which CPU, how much cycles such cpu consumed in
user vs kernel, and how many packets were seen on such nic; then you
should have the info necessary to make a decision, no? Yes, I know it is
a handwave on my part and it is complex but by the same token, I would
suspect each kind of IO derived work (which results in interupts) will
have more inputs that could help you make a proper decision than a mere
glance of the interupts. I understand for example the SCSI subsystem
these days behaves very much like NAPI.
I think one of the failures of the APIC load balancing is a direct
result of not being able to factor in such enviromental factors.
> also the "amount of work" estimate doesn't need to be accurate to 5
> digits to be honest... just number of packets seems to be a quite
> reasonable approximation already. (if the kernel starts exporting more
> accurate data, irqbalance can easily use it of course)
It is certainly much more promising now than before. Most people will
probably have symettrical type of apps, so it should work for them.
For someone like myself i will still not use it because i typically dont
have symettrical loads.
cheers,
jamal
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists