linux-kernel - Re: [PATCH v2 0/3] Deferrable timers support for timerfd API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <52F3CAA2.3070705@linaro.org>
Date:	Thu, 06 Feb 2014 09:47:14 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Alexey Perevalov <a.perevalov@...sung.com>,
	Thomas Gleixner <tglx@...utronix.de>
CC:	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/06/2014 09:38 AM, Alexey Perevalov wrote:
> On 02/06/2014 02:16 AM, Thomas Gleixner wrote:
>> On Wed, 5 Feb 2014, John Stultz wrote: 
>>> My reasoning was that the deferrablity isn't a clock domain, and is
>>> more
>>> of a modifier. Thus to keep the interfaces somewhat sane (and avoiding
>>> having to add N new clockids for each new modifier), we should utilize
>>> the flag arguments to timers. So instead of just having TIMER_ABSTIME,
>>> we could add TIMER_DEFER, etc, which we could utilize instead.
>> I can see the point. I have no objections against that approach as
>> long as we map that against separate internal bases.
>>  
>>> Internally we can still keep separate bases, much as your patch
>>> does, to
>>> keep the next-event searching overhead more limited.
>> It's not only more limited, it's bound.
>>  
>>> I mainly wanted to get your thoughts on extending the flags, and doing
>>> so in a consistent manner between the timerfd and other timer
>>> interfaces.
>> So the only interface which does not support that is sys_nanosleep()
>> but that's not really an issue. sys_nanosleep() should die anyway :)
>>
>>> Of course, all this is after I added the _ALARM clockids... so you can
>>> decide if its hypocrisy or experience.
>>> (The "old wisdom comes from experience and experience comes from bad
>>> decisions" bit ;).
>> Well, you have a valid point about the clock ids. I did not realize in
>> the first place that we can avoid that business if we use the flags to
>> select the internal representation.
>>
>> Either way is preferred over reintroducing the timer wheel mess....
>
> 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.
> If so, it's in v2 patch set.

So, I think Thomas is suggesting we add new deferrable HRTIMER bases,
then the timerfd code would only use the hrtimers for non-alarm-timers.
We would then use the flag from the interface to decide internally which
base to add the hrtimer to. This would also allow us to use the flag via
non-timerfd interfaces to get the same result.

Does that clarify things?

thanks
-john




--
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/