[Prev][Next][Index][Thread]
Re: Request for suggestions
At a high-level, what does your code do? Is it computational? Is it
serialized by network messaages such that dropping packets would seriously
affect performance? What version of Linux? Are your hub/switch half-duplex?
Full-duplex? Auto-sensing?
Things we have seen before:
LMM memory allocator slowdowns. Its a simple linked list, so when the
free list starts to fragment, performance degrades. As Jonathan suggested,
you can use the LMM as a bulk-allocator and use some specialized allocator
(e.g., a free list) for packet alloction (or for whatever your heavy-hitters
are).
Extra data copy on network transmission due to mapping between BSD mbufs
and Linux skbufs. A multi-mbuf packet has to be copied to contiguous memory
for use by the Linux drivers on transmission.
Duplex/flow-control problems. More recently we have seen problems with
duplex and flow control on switches. Some of the OSKit versions of Linux
drivers hardwire the card in full duplex mode. If the switch thinks you are
in half-duplex and you have a fair amount of traffic in both directions,
the switch will see a lot of collisions and back off, while the OSKit kernel
will just continue to blast away.
The eepro100 card, can get in a state where it pumps out a steady stream of
flow control packets, causing tremendous grief (though I think I hacked
around that in the latest OSKit snapshot).
At least one of the Linux 2.1.x drivers we use (cs89x0 on the ARM)
doesn't support detection/setting of flow control at all, where the
current Linux driver does. Now you could be operating in half-duplex
mode where the switch is operating in full-duplex.
As Pat says, profile.