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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.