From: Jon Hunter <jon-hunter@ti.com>
To: john stultz <johnstul@us.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for more than 2.15 seconds
Date: Tue, 21 Apr 2009 18:20:20 -0500 [thread overview]
Message-ID: <49EE54B4.9020700@ti.com> (raw)
In-Reply-To: <1240345936.6080.6.camel@localhost>
john stultz wrote:
> The concern is many clocksources wrap after a handful of seconds. The
> acpi_pm is the best example (its only 24 bits wide).
>
> I brought this issue up earlier, and provided some example code that
> could be used to limit the idle time appropriately for the current
> clocksource here:
>
> http://lkml.indiana.edu/hypermail/linux/kernel/0901.3/02693.html
>
> Jon: Did you see that mail, or is there a reason you didn't adapt this
> code into your patch?
Hi John, yes I did read this email and thanks for bringing this up.
As I looked at this more I noticed that for 64-bit machines that the
max_delta_ns would be a 64-bit integer already and so this change would
only have an impact for 32-bit machines. I understand that there are
more 32-bit machines that 64-bit. However, I was trying to understand
how the wrapping of clocksources, such as the one you mention above, is
handled today for 64-bit machines that could theoretically sleep for
longer periods.
In addition to this as I was reviewing the "tick_nohz_stop_sched_tick()"
function that is configuring the dynamic tick and I noticed that this
code would actually stop the timer altogether if the time for the next
timer event is greater than NEXT_TIMER_MAX_DELTA jiffies. See code
snippet below. This is very unlikely, however, if this scenario was to
occur what would be the impact on the clocksource?
/*
* delta_jiffies >= NEXT_TIMER_MAX_DELTA signals that
* there is no timer pending or at least extremly far
* into the future (12 days for HZ=1000). In this case
* we simply stop the tick timer:
*/
if (unlikely(delta_jiffies >= NEXT_TIMER_MAX_DELTA)) {
ts->idle_expires.tv64 = KTIME_MAX;
if (ts->nohz_mode == NOHZ_MODE_HIGHRES)
hrtimer_cancel(&ts->sched_timer);
goto out;
}
I understand that clocksources need to be handled correctly, but as I
looked into this more I wanted to clarify how this is handled today for
64-bit machines. I appreciate your comments and feedback.
Cheers
Jon
next prev parent reply other threads:[~2009-04-21 23:21 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-20 21:16 [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for more than 2.15 seconds Jon Hunter
2009-04-21 6:35 ` Ingo Molnar
2009-04-21 20:32 ` john stultz
2009-04-21 23:20 ` Jon Hunter [this message]
2009-04-22 0:02 ` john stultz
2009-05-07 14:52 ` Jon Hunter
2009-05-08 0:54 ` [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep formore " john stultz
2009-05-08 16:05 ` Jon Hunter
2009-05-09 0:51 ` [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep formorethan " john stultz
2009-05-12 23:35 ` Jon Hunter
2009-05-12 23:58 ` [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep formorethan2.15 seconds john stultz
2009-05-13 15:14 ` Jon Hunter
2009-05-13 16:41 ` John Stultz
2009-05-13 17:54 ` Jon Hunter
2009-05-13 19:21 ` John Stultz
2009-05-15 16:35 ` Jon Hunter
2009-05-15 18:55 ` Jon Hunter
2009-05-16 1:29 ` John Stultz
2009-05-16 1:18 ` John Stultz
2009-05-22 18:21 ` Jon Hunter
2009-05-22 19:23 ` john stultz
2009-05-22 19:54 ` Thomas Gleixner
2009-05-26 15:12 ` Jon Hunter
2009-05-26 20:26 ` john stultz
2009-05-22 19:59 ` Thomas Gleixner
2009-04-22 0:05 ` [RFC][PATCH] Dynamic Tick: Allow 32-bit machines to sleep for more than 2.15 seconds john stultz
2009-04-22 3:07 ` Jon Hunter
2009-04-22 15:30 ` Chris Friesen
2009-04-22 17:04 ` Jon Hunter
2009-04-22 18:53 ` Geert Uytterhoeven
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=49EE54B4.9020700@ti.com \
--to=jon-hunter@ti.com \
--cc=johnstul@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--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.