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... MCLGETI ?? Is it in if_em.c if I want to see how it is implemented? > >> 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. Tnx /Per-Olov GPG keyID: 5231C0C4 GPG fingerprint: B232 3E1A F5AB 5E10 7561 6739 766E D29D 5231 C0C4 GPG key: http://wwwkeys.eu.pgp.net/pks/lookup?op=get&search=0x766ED29D5231C0C4
