device polling and weird timer interrupt count from vmstat

Oliver Fromme olli at
Tue Sep 25 06:53:36 PDT 2007

Artem Kuchin wrote:
 > Oliver Fromme wrote:
 > > Artem Kuchin wrote:
 > > > 3) Is timer int really generated on each cpu? Am i really wasting
 > > > cpu time on ~4000 ints per second?
 > > 
 > > 4000 ints per second is rather nothing on any modern CPU.
 > > Have a look at the top(1) display of an otherwise idle
 > > system.  The "%interrupt" column should be zero, even if
 > > it's processing 4000 timer interrupts per second.  As far
 > > as I know, the cpu timer interrupt handler is very light-
 > > weight.
 > Thank you for the answer. My convern is that with 4 CPUs i get 8000
 > ints/second.  While em generates only about 200 ints/second. As i
 > undertand not all int handlers are the same. Some are heavy and some
 > are light on CPU. So, the question is what is better (better=less CPU
 > time): 8000 ints/sec from timer or 200 ints/sec from NIC?

There's no simple answer to the question.  The best way is
to just try it.  As I wrote, run top(1) while the system is
idle, so only the cpu timer interrupts are active.  If the
"%interrupt" column is zero most of the time, then there
is nothing to worry about at all.

However, if you have a constant non-zero %interrupt value,
you might consider lowering HZ, and you might reconsider
whether polling really has advantages in your situation.
Do you have reasons to believe so?  Remember that the main
purpose of polling is to improve interactivity under very
high network load.  If you're not in such a situation, then
polling probably doesn't buy you much.

Best regards

Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart

FreeBSD-Dienstleistungen, -Produkte und mehr:

"Documentation is like sex; when it's good, it's very, very good,
and when it's bad, it's better than nothing."
        -- Dick Brandon

More information about the freebsd-stable mailing list