Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 25 Sep 2007 14:11:39 -0400
From:      Michael Proto <mike@jellydonut.org>
To:        Artem Kuchin <matrix@itlegion.ru>
Cc:        freebsd-stable@FreeBSD.ORG
Subject:   Re: device polling and weird timer interrupt count from vmstat
Message-ID:  <46F94F5B.9050102@jellydonut.org>
In-Reply-To: <000f01c7ff9a$03b887e0$0c00a8c0@Artem>
References:  <200709251352.l8PDqD2x003565@lurza.secnetix.de> <000f01c7ff9a$03b887e0$0c00a8c0@Artem>

next in thread | previous in thread | raw e-mail | index | archive | help


Artem Kuchin wrote:
> Oliver Fromme wrote:
>> 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.
> 
> Well, problem with top is that on dual 3GHZ box it alsway s
> shows 0% load when not loaded with real traffic (web traffic) no matter
> if it is polling of int handling. And when loaded with real traffic
> web server eat a lot more cpu power then traffic handling, so, no
> separate measurement of traffic cpu load is possible.
> But i think it is possible to simulate this kind of load, need to think
> about
> it.
> 
> Also, when it comes to public web server i can never be secure enough and
> crazy load of traffic can come any time from DDOS attack which can bring
> down any box. So, for public web server it is a matter of security and
> managebility to have server interactive even on high traffic load. So,
> even from
> this poing of view polling can be usefull.
> 

Would it not be advisable then to simply limit the maximum number of
allowed connections, ala sysctl kern.ipc.somaxconn, rather then to
enable polling? I can see using polling on a router or some device that
funnels traffic through multiple interfaces, but rarely have I seen it
useful on a single-homed box where sysctls might be better used to limit
connections. May be old news, but I've read that polling on a SMP
machine is questionable anyway (http://info.iet.unipi.it/~luigi/polling/).


-Proto



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?46F94F5B.9050102>