mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: john stultz <johnstul@us.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] Sanity check sysfs clocksource changes
Date: Tue, 5 May 2009 08:48:28 +0200 (CEST)	[thread overview]
Message-ID: <alpine.LFD.2.00.0905050839560.3375@localhost.localdomain> (raw)
In-Reply-To: <1241493035.7444.115.camel@localhost.localdomain>

On Mon, 4 May 2009, john stultz wrote:

> On Fri, 2009-05-01 at 13:10 -0700, Andrew Morton wrote:
> > What's the status of
> > clocksource-sanity-check-sysfs-clocksource-changes.patch, btw?  I have
> > it marked as "still an RFC", but it's been sitting here since January?
> 
> Thanks for reminding me! I lost track of that one. Still waiting on
> feedback from Thomas.
> 
> Thomas? What do you think? Original patch below, applies with fuzz and
> builds.
> 
> -john
> 
> 
> Hey all,
> 	Thomas, Andrew and Ingo pointed out that we don't have any safety
> checks in the clocksource sysfs entries to make sure sysadmins don't try
> to change the clocksource to a non high-res timer capable clocksource
> (such as jiffies) when high-res timers (HRT) is enabled. Doing so will
> likely hang a system.
> 
> This patch tries to correct this by filtering non HRT clocksources from
> available_clocksources and not accepting non HRT clocksources with HRT
> is is enabled.
> 
> This has been lightly tested, and seems to work, but there may be some
> drawbacks.
> 
> One issue I realized was that when TSCs disqualified, they are marked as
> not CLOCK_SOURCE_VALID_FOR_HRES. This means on boxes with unsycned TSCs,
> the only available clocksource may be the slower acpi_pm and the user
> will not be able to override it with the TSC as is currently possible.
> (even if that seems ill-advised).
> 
> So Thomas, what do you think? Should we just use
> CLOCK_SOURCE_IS_CONTINUOUS flag or is CLOCK_SOURCE_VALID_FOR_HRES really
> what we want?

Hmm. If we switched to highres and discarded TSC already then we
should not go back to it. 
 
> Signed-off-by: John Stultz <johnstul@us.ibm.com>
> 
> 
> diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
> index bd37078..05f67f0 100644
> --- a/include/linux/hrtimer.h
> +++ b/include/linux/hrtimer.h
> @@ -305,7 +305,7 @@ static inline int hrtimer_is_hres_active(struct hrtimer *timer)
>  
>  extern ktime_t ktime_get(void);
>  extern ktime_t ktime_get_real(void);
> -
> +extern int hrtimer_hres_active(void);
>  
>  DECLARE_PER_CPU(struct tick_device, tick_cpu_device);
>  
> diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
> index 2dc30c5..fa4abdc 100644
> --- a/kernel/hrtimer.c
> +++ b/kernel/hrtimer.c
> @@ -476,7 +476,7 @@ static inline int hrtimer_is_hres_enabled(void)
>  /*
>   * Is the high resolution mode active ?
>   */
> -static inline int hrtimer_hres_active(void)
> +int hrtimer_hres_active(void)
>  {
>  	return __get_cpu_var(hrtimer_bases).hres_active;
>  }
> @@ -689,7 +689,7 @@ static int hrtimer_switch_to_hres(void)
>  
>  #else
>  
> -static inline int hrtimer_hres_active(void) { return 0; }
> +int hrtimer_hres_active(void) { return 0; }

We want to keep that static inline and move it to hrtimer.h to allow
gcc to optimize stuff out.

Thanks,

	tglx





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

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-15  1:32 [RESEND][PATCH 0/2] Convert acked !GENERIC_TIME architectures to use the generic timekeeping core john stultz
2009-04-15  1:34 ` [RESEND][PATCH 1/2] Create arch_gettimeoffset infrastructure for use in " john stultz
2009-04-15  1:36   ` [RESEND][PATCH 2/2] Convert sh to use arch_getoffset() infrastructure john stultz
2009-04-15  1:39     ` [RFC][PATCH 1/8] Convert alpha " john stultz
2009-04-15  1:41       ` [RFC][PATCH 2/8] Convert arm " john stultz
2009-04-15  1:43         ` [RFC][PATCH 3/8] Convert blackfin " john stultz
2009-04-15  1:44           ` [RFC][PATCH 4/8] Convert cris " john stultz
2009-04-15  1:45             ` [RFC][PATCH 5/8] Convert m32r " john stultz
2009-04-15  1:46               ` [RFC][PATCH 6/8] Convert m68k " john stultz
2009-04-15  1:51                 ` [RFC][PATCH 7/8] Convert sparc " john stultz
2009-04-15  1:53                   ` [RFC][PATCH 8/8] Remove CONFIG_GENERIC_TIME john stultz
2009-04-15  2:51                   ` [RFC][PATCH 7/8] Convert sparc to use arch_getoffset() infrastructure David Miller
2009-04-16  7:36         ` [RFC][PATCH 2/8] Convert arm " Russell King
2009-05-01 20:10     ` [RESEND][PATCH 2/2] Convert sh " Andrew Morton
2009-05-02  1:04       ` Paul Mundt
2009-05-05  3:10       ` [PATCH] Sanity check sysfs clocksource changes john stultz
2009-05-05  6:48         ` Thomas Gleixner [this message]
2009-05-07  0:47           ` john stultz

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=alpine.LFD.2.00.0905050839560.3375@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=akpm@linux-foundation.org \
    --cc=johnstul@us.ibm.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

all inboxes | Powered by JetHome®