Timing issue with Dummynet on high kernel timer interrupt

[Hans Petter Selasky]

On 11/06/15 09:50, Luigi Rizzo wrote:
> On Fri, Nov 6, 2015 at 9:44 AM, Hans Petter Selasky <hps at selasky.org> wrote:
>> On 11/06/15 01:08, Rasool Al-Saadi wrote:
>>>
>>>
>>> On Thursday, 5 November 2015 8:53 PM, Hans Petter Selasky wrote:
>>>>
>>>>
>>>> On 11/05/15 00:44, Rasool Al-Saadi wrote:
> ...
>>> Removing C_HARDCLOCK reduces the problem but doesn't  solve it completely.
>>> However, removing  C_DIRECT_EXEC  instead solves the problem (but
>>> occasionally  very small spike(s) appears in high hz values).
>>> I mentioned in my first email that removing these flags makes the issue to
>>> disappear. But what the effects of removing these flags? If it cause timing
>>> issue to Dummynet, why we should use them?
>>>
>>
>> Hi,
>>
>> The C_DIRECT_EXEC flag reduces task switching overhead, that you don't have
>> to wakeup a thread to wakeup the dummynet worker thread. It affects timing.
>
> Hans,
> thanks for the explanation.
>
> Can you clarify the behaviour of C_DIRECT_EXEC ?
> Does this mean that the task is run within some common
> thread instead of a dedicated one ?

Hi Luigi,

C_DIRECT_EXEC means that the timer callback is executed directly from 
the fast interrupt filter of the timer or IPI.

>
> If so, for this type of task (dummynet may run at high rate
> and use a significant amount of cpu time) it may be a good
> idea to remove C_DIRECT_EXEC altogether.

The ipfw dummynet code is not run from the timer callback. It is run 
from a taskqueue. I suspect there is likely a bug somewhere. At the 
moment it is not clear to me if there is a bug in the callout subsystem, 
that the when the timer is started with 1 tick delay it doesn't kick in 
until after 50ms or so at HZ=4000. Or if the dummynet's task is doing a 
lot of work for 50ms. I think we need some more information to nail this 
one.

--HPS

>
> cheers
> luigi
>