linux-kernel - Re: [PATCH 3/3] timerfd: Add support for deferrable timers

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: <52C5BED6.5090603@linaro.org>
Date:	Thu, 02 Jan 2014 11:32:38 -0800
From:	John Stultz <john.stultz@...aro.org>
To:	Alexey Perevalov <a.perevalov@...sung.com>,
	linux-kernel@...r.kernel.org
CC:	Anton Vorontsov <anton@...msg.org>, kyungmin.park@...sung.com,
	akpm@...ux-foundation.org,
	Anton Vorontsov <anton.vorontsov@...aro.org>
Subject: Re: [PATCH 3/3] timerfd: Add support for deferrable timers

On 01/02/2014 10:30 AM, Alexey Perevalov wrote:
> From: Anton Vorontsov <anton@...msg.org>
>
> This patch implements a userland-side API for generic deferrable timers,
> per linux/timer.h:
>
>  * A deferrable timer will work normally when the system is busy, but
>  * will not cause a CPU to come out of idle just to service it; instead,
>  * the timer will be serviced when the CPU eventually wakes up with a
>  * subsequent non-deferrable timer.
>
> These timers are crucial for power saving, i.e. periodic tasks that want
> to work in background when the system is under use, but don't want to
> cause wakeups themselves.
>
> The deferred timers are somewhat orthogonal to high-res external timers,
> since the deferred timer is tied to the system load, not just to some
> external decrementer source.
>
> So, currently, the implementation has a HZ precision, and the maximum
> interval is jiffies resolution (i.e. with HZ=1000, on 32 bit that would
> be around max 49 days).  Of course we can implement longer timeouts by
> rearming the timer, although it probably  wouldn't make much sense in
> real world, so we keep it simple and just return E2BIG if we don't like
> the interval.
>
> Signed-off-by: Anton Vorontsov <anton.vorontsov@...aro.org>
> Signed-off-by: Alexey Perevalov <a.perevalov@...sung.com>
> ---
>  fs/timerfd.c              |   59 ++++++++++++++++++++++++++++++++++++++++++---
>  include/uapi/linux/time.h |    1 +
>  2 files changed, 56 insertions(+), 4 deletions(-)
>
> diff --git a/fs/timerfd.c b/fs/timerfd.c
> index 3561ce7..331ce4b 100644
> --- a/fs/timerfd.c
> +++ b/fs/timerfd.c
> @@ -30,6 +30,7 @@ struct timerfd_ctx {
>  	union {
>  		struct hrtimer tmr;
>  		struct alarm alarm;
> +		struct timer_list dtmr;
>  	} t;
>  	ktime_t tintv;
>  	ktime_t moffs;
> @@ -51,6 +52,11 @@ static inline bool isalarm(struct timerfd_ctx *ctx)
>  		ctx->clockid == CLOCK_BOOTTIME_ALARM;
>  }
>  
> +static inline bool isdeferrable(struct timerfd_ctx *ctx)
> +{
> +	return ctx->clockid == CLOCK_DEFERRABLE;
> +}
> +
>  /*
>   * This gets called when the timer event triggers. We set the "expired"
>   * flag, but we do not re-arm the timer (in case it's necessary,
[snip]
> diff --git a/include/uapi/linux/time.h b/include/uapi/linux/time.h
> index e75e1b6..3481cb3 100644
> --- a/include/uapi/linux/time.h
> +++ b/include/uapi/linux/time.h
> @@ -56,6 +56,7 @@ struct itimerval {
>  #define CLOCK_BOOTTIME_ALARM		9
>  #define CLOCK_SGI_CYCLE			10	/* Hardware specific */
>  #define CLOCK_TAI			11
> +#define CLOCK_DEFERRABLE		12
>  
>  #define MAX_CLOCKS			16
>  #define CLOCKS_MASK			(CLOCK_REALTIME | CLOCK_MONOTONIC)


So, I'm a bit concerned about the CLOCK_DEFERRABLE clockid, as it isn't
clear what time domain it uses. Its unlikely to be its own time domain,
so this is really a misuse of extending the clockids.

It seems to me that deferrability is an attribute of the time domain. So
instead of having a CLOCK_DEFERRABLE, I suspect we'll want something
like CLOCK_MONOTONIC_DEFER/CLOCK_REALTIME_DEFER, etc.

That is, unless we extend the timerfd interface to also take something
like a properties flag or something.

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/