On Mon, Aug 22, 2011 at 10:49:47PM +0200, Per-Olov Sjvholm wrote: > On 22 aug 2011, at 22:04, Stuart Henderson wrote: > >> But if you can give hints of how to decrease the interrupt load I am all > ears. > >> As I see it, if the interrupt handling model i OpenBSD would change to a > >> polling one u could maybe increase the throughput at the same processor > speed > >> (just me guessing though). But now the fact is that it is not polling. So > what > >> can I do with what we have.... > > > > polling is one mechanism to ensure you aren't handling interrupts all the > > time, so you can ensure userland remains responsive even when the machine > is > > under heavy network load. OpenBSD has another way to handle this, MCLGETI. > > > With polling if I get it right the context switch overhead is mostly avoided > because the system can choose to look at the device when it is already in the > right context. The drawback could be increased latency in processsing events > in a polling model. But according to what I have read, the latency is reduced > to a very low low values by raising the clock interrupt frequency. They say > polling is better from a OS "time spent on device" control perspective. Note > that I am not a pro in this area, but will for sure look deeper...
Polling only works reliably at insane HZ settings which will cause other issues at other places (some obvious some not so obvious). In the end polling is a poor mans interrupt mitigation (which is also enabled on em(4) btw.) since instead of using the interrupt of the network card you use the interrupt of the clock to process the DMA rings. Polling does not gain you much on good modern HW. > MCLGETI ?? Is it in if_em.c if I want to see how it is implemented? > Yes. em(4) has MCLGETI(). > > > >> Is pure cpu speed the only way? Or is it possible to decrease the > interrupt > >> load with even better NIC:s? > > > > here are some things that might help: > > > > - faster cpu > > - larger cpu cache > > - faster ram > > - reduce overheads (things like switching VM context while handling > > packets is not going to help matters) > > - improving code efficiency > > > > have you tried -current? > > > > > > I tried to share and use the same interrupt for my network ports as I have a > guess it could be a boost, but the bios did not want what I wanted.... > Interrupts could be shared, but not between the ports I wanted. I simple did > not understand the interrupt allocation scheme in my Dell T410 tower server. > > Have not tried current, but will try current as soon as I can. Also... I will > try to do some laborations with CPU speed of the core the OpenBSD virtual > machine has. This to see how the interrupts and throughput is related to the > CPU speed of the allocated core. > Also make sure that the guest can actually access the physical HW directly without any virtualisation in between. In the end real HW is going to have less overhead and will be faster then a VM solution. -- :wq Claudio
