On Sat, Jun 29, 2002 at 07:08:44PM -0400, Bosko Milekic wrote:
...
> I would prefer to see an interface that just grabs both a cluster and
> an mbuf from their respective per-CPU caches (in -CURRENT) while only
> grabbing the lock once, if at all this is that important to you. [*]
I have to say i did the tests on a -stable uniprocessor box, so the
locking costs are almost negligible there, and all the gain that
i measured comes from not having to do the bookkeeping. On -current,
I have no idea.
But i wonder, which CPU gets to serve the interrupt handler (or
equivalently, the polling loop) ? Is it picked up at random, or
it is statically assigned to devices or irq lines or what ?
Because the per-CPU allocation may or may not be a good idea
depending on the above -- e.g. if the receiving and transmitting
interrupt handler end up on different CPUs then the cache becomes
totally useless (and i am not mentioning those clusters freed in the
protocol stack because that still runs under Giant and it will
take a while before it can be parallelised).
cheers
luigi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
