linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: John Stultz <john.stultz@linaro.org>
To: Alexey Perevalov <a.perevalov@samsung.com>, linux-kernel@vger.kernel.org
Cc: Anton Vorontsov <anton@enomsg.org>,
	kyungmin.park@samsung.com, akpm@linux-foundation.org,
	Anton Vorontsov <anton.vorontsov@linaro.org>
Subject: Re: [PATCH 3/3] timerfd: Add support for deferrable timers
Date: Thu, 02 Jan 2014 11:32:38 -0800	[thread overview]
Message-ID: <52C5BED6.5090603@linaro.org> (raw)
In-Reply-To: <1388687448-12987-4-git-send-email-a.perevalov@samsung.com>

On 01/02/2014 10:30 AM, Alexey Perevalov wrote:
> From: Anton Vorontsov <anton@enomsg.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@linaro.org>
> Signed-off-by: Alexey Perevalov <a.perevalov@samsung.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







  reply	other threads:[~2014-01-02 19:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02 18:30 [PATCH 0/3] Deferrable timers support for timerfd API Alexey Perevalov
2014-01-02 18:30 ` [PATCH 1/3] kernel/time: Add new helpers to convert ktime to/from jiffies Alexey Perevalov
2014-01-02 18:30 ` [PATCH 2/3] timerfd: Factor out timer-type unspecific timerfd_expire() Alexey Perevalov
2014-01-02 18:30 ` [PATCH 3/3] timerfd: Add support for deferrable timers Alexey Perevalov
2014-01-02 19:32   ` John Stultz [this message]
2014-01-02 23:17 ` [PATCH 0/3] Deferrable timers support for timerfd API John Stultz
2014-01-03 17:45   ` Alexey Perevalov
2014-01-04  0:18     ` John Stultz
2014-01-05 19:33       ` Alexey Perevalov
2014-01-09 20:32         ` John Stultz
2014-01-12 17:16           ` Alexey Perevalov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=52C5BED6.5090603@linaro.org \
    --to=john.stultz@linaro.org \
    --cc=a.perevalov@samsung.com \
    --cc=akpm@linux-foundation.org \
    --cc=anton.vorontsov@linaro.org \
    --cc=anton@enomsg.org \
    --cc=kyungmin.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).