Date:	Sun, 16 Feb 2014 19:20:50 +0400
From:	Alexey Perevalov <a.perevalov@...sung.com>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	John Stultz <john.stultz@...aro.org>, linux-kernel@...r.kernel.org,
	anton@...msg.org, kyungmin.park@...sung.com,
	akpm@...ux-foundation.org, cw00.choi@...sung.com
Subject: Re: [PATCH v2 0/3] Deferrable timers support for timerfd API

On 02/07/2014 12:50 AM, Thomas Gleixner wrote:
> On Thu, 6 Feb 2014, Alexey Perevalov wrote:
>> On 02/06/2014 02:16 AM, Thomas Gleixner wrote:
>> As I truly understand, you decided - flags is better than new clockids, and
>> internals of timerfd could be a mix of timer_list and hrtimer.
> NO, NO, NO, NO. There is no mix of timer_list and hrtimer. Either we
> add proper deferrable support to hrtimers or the whole thing is not
> going to happen at all. There is no way that we bring back timer_list
> to user space interfaces. Period.
>
> Thanks,
>
> 	tglx
>
>
>
Hello Thomas,
I checked you patch on system with CONFIG_HZ=250,
Here is result for hrtimer with 200ms interval
[291943.009557] time delta 209518762
[291943.205546] time delta 195995131
[291943.403012] time delta 197466387
[291943.610090] time delta 207071848
[291943.816138] time delta 206054438
[291944.000063] time delta 183918221
[291944.209290] time delta 209234301
[291944.405104] time delta 195813256
[291944.601507] time delta 196396567
[291944.816090] time delta 214589122
[291945.000125] time delta 184034925
[291945.214207] time delta 214075670

Maximum delay is 14 ms, but sometimes timer function is called early.

On the same system deferrable timer_list looks like:
[292214.336130] time delta 248064082
[292214.548061] time delta 211932930
[292214.804028] time delta 255964215
[292215.080160] time delta 276133570
[292215.328212] time delta 248043192
[292215.576241] time delta 248043616
[292215.796066] time delta 219818102
[292216.004040] time delta 207973662
[292216.260111] time delta 256069522
[292216.568160] time delta 308049741
[292216.816120] time delta 247962559
[292217.028062] time delta 211941369
[292217.264078] time delta 236013934

Maximum delay is 108 ms. And it looks like more predictable.

After I changed CONFIG_HZ=200,
hrtimer charged for 200ms had shown following result:

[  187.548009] time delta 200360371
[  187.724141] time delta 176132213
[  187.826221] time delta 102085975
[  188.008010] time delta 181788726
[  188.312062] time delta 304051846
[  188.705480] time delta 393417803
[  188.800070] time delta 94583497
[  189.000125] time delta 200055104
[  189.224055] time delta 223937438
[  189.400065] time delta 176009338
[  189.672916] time delta 272851573
[  189.828029] time delta 155112014
[  190.000047] time delta 172018578

Now it has maximum delay 193 ms (393417803), but in other times it 
triggers early.
Normal deferrable timer behaves as expected (time delta is 200ms).
These examples were made with MONOTONIC timers.

As I understand main idea in hrtimer.c was do not decrement expires_next 
in case of DEFERRABLE timers type.
Such small average delay could be explained: it's due higher resolution, 
and cpu is not in idle when we in hrtimer_interrupt,
with timer_list decrementing process not so often.
In this case it's hard to me to explain such small "time delta", it 
occurs almost every time we have larger delay.

-- 
Best regards,
Alexey Perevalov
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists