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 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).