All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: Chris Peterson <cpeterso@cpeterso.com>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de
Subject: Re: [RFC] mod_timer() helper functions?
Date: Sat, 16 May 2009 23:03:50 -0700	[thread overview]
Message-ID: <20090516230350.ec4fb487.akpm@linux-foundation.org> (raw)
In-Reply-To: <a24804730905160036j2720c557o347cec1513df9c4a@mail.gmail.com>

On Sat, 16 May 2009 00:36:15 -0700 Chris Peterson <cpeterso@cpeterso.com> wrote:

> Reviewing the kernel's nearly one-thousand calls to mod_timer(), there
> are three basic patterns:
> 
>  * multi-second timeouts
>  * millisecond timeouts
>  * +1 jiffie ASAP events
> 
> Few mod_timer() calls actually use the function's 'expires' deadline
> time without manually calculating 'jiffies + delay'. The following
> helper functions could provide a simpler, more descriptive interface
> than the low-level mod_timer() function. Also, when scheduling longer
> timers, these helper functions could use round_jiffies() to (secretly)
> batch timers on whole seconds to reduce power usage.
> 
> Any suggestions? Is there enough value to warrant adding helper
> function like these as an alternative to mod_timer()?
> 
> 
> chris
> 
> ---
> static inline int mod_timer_seconds(struct timer_list *timer, time_t seconds)
> {
> 	return mod_timer(timer, round_jiffies(jiffies + seconds * HZ));
> }
> 
> static inline int mod_timer_msecs(struct timer_list *timer, unsigned int msecs)
> {
> 	/* TODO? Round jiffies if within some epsilon of a whole second? */
> 	return mod_timer(timer, jiffies + msecs_to_jiffies(msecs));
> }
> 
> static inline int mod_timer_yield(struct timer_list *timer)
> {
> 	/* After these messages, we'll be right back. */
> 	return mod_timer(timer, jiffies + 1);
> }

I think it makes sense, yes.

I do think that the name should be changed to communicate the fact that
the change is relative.  advance_timer_foo(), perhaps.

Or, if you want to put lipstick on our pig, timer_advance_foo().  All
these API functions should have started with "timer_" but we screwed
that up ages ago.

I expect that most/all of these functions will be too large to inline,
btw.  Check the generated code and I expect you'll be surprised how
porky they are.

  reply	other threads:[~2009-05-17  6:04 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-16  7:36 [RFC] mod_timer() helper functions? Chris Peterson
2009-05-17  6:03 ` Andrew Morton [this message]
2009-05-17  7:50   ` Chris Peterson
2009-05-17  8:03     ` Andrew Morton
2009-05-17 12:13       ` Thomas Gleixner
2009-05-18  7:14 ` Andi Kleen
2009-05-20  7:11   ` Chris Peterson
2009-05-20  8:14     ` Andi Kleen
2009-05-21  5:11       ` Chris Peterson

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=20090516230350.ec4fb487.akpm@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=cpeterso@cpeterso.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /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.