Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1740691 > unrolled thread

Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Peter Zijlstra <peterz@infradead.org> - 2017-09-27 15:00 +0200
    Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-09-27 15:20 +0200
      Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-09-27 16:00 +0200
        Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-09-27 19:20 +0200
        Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Peter Zijlstra <peterz@infradead.org> - 2017-09-27 20:10 +0200
          Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Peter Zijlstra <peterz@infradead.org> - 2017-09-27 20:20 +0200
            Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-09-28 12:10 +0200
              Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Peter Zijlstra <peterz@infradead.org> - 2017-09-28 14:00 +0200
                Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Thomas Gleixner <tglx@linutronix.de> - 2017-09-28 14:20 +0200
                  Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Pasha Tatashin <pasha.tatashin@oracle.com> - 2017-09-28 15:20 +0200
                    Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Dou Liyang <douly.fnst@cn.fujitsu.com> - 2017-09-29 17:10 +0200
    Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early  in boot Peter Zijlstra <peterz@infradead.org> - 2017-09-27 15:20 +0200

#1740691 — Re: [PATCH v6 1/4] sched/clock: interface to allow timestamps early in boot

On Wed, Aug 30, 2017 at 02:03:22PM -0400, Pavel Tatashin wrote:
> In Linux printk() can output timestamps next to every line.  This is very
> useful for tracking regressions, and finding places that can be optimized.
> However, the timestamps are available only later in boot. On smaller
> machines it is insignificant amount of time, but on larger it can be many
> seconds or even minutes into the boot process.
> 
> This patch adds an interface for platforms with unstable sched clock to
> show timestamps early in boot. In order to get this functionality a
> platform must:
> 
> - Implement u64 sched_clock_early()
>   Clock that returns monotonic time
> 
> - Call sched_clock_early_init()
>   Tells sched clock that the early clock can be used
> 
> - Call sched_clock_early_fini()
>   Tells sched clock that the early clock is finished, and sched clock
>   should hand over the operation to permanent clock.
> 
> Signed-off-by: Pavel Tatashin <pasha.tatashin@oracle.com>

Urgh, that's horrific.

Can't we simply make sched_clock() go earlier? (we're violating "notsc"
in any case and really should kill that option).

Then we can do something like so on top...


---
 include/linux/sched/clock.h |  6 +++++-
 kernel/sched/clock.c        | 42 +++++++++++++++++++++++++++---------------
 2 files changed, 32 insertions(+), 16 deletions(-)

diff --git a/include/linux/sched/clock.h b/include/linux/sched/clock.h
index a55600ffdf4b..986d14a208e7 100644
--- a/include/linux/sched/clock.h
+++ b/include/linux/sched/clock.h
@@ -20,9 +20,12 @@ extern u64 running_clock(void);
 extern u64 sched_clock_cpu(int cpu);
 
 
-extern void sched_clock_init(void);
 
 #ifndef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
+static inline void sched_clock_init(void)
+{
+}
+
 static inline void sched_clock_tick(void)
 {
 }
@@ -49,6 +52,7 @@ static inline u64 local_clock(void)
 	return sched_clock();
 }
 #else
+extern void sched_clock_init(void);
 extern int sched_clock_stable(void);
 extern void clear_sched_clock_stable(void);
 
diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index ca0f8fc945c6..47d13d37f2f1 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -80,11 +80,6 @@ EXPORT_SYMBOL_GPL(sched_clock);
 
 __read_mostly int sched_clock_running;
 
-void sched_clock_init(void)
-{
-	sched_clock_running = 1;
-}
-
 #ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
 /*
  * We must start with !__sched_clock_stable because the unstable -> stable
@@ -211,6 +206,31 @@ void clear_sched_clock_stable(void)
 		__clear_sched_clock_stable();
 }
 
+static void __sched_clock_gtod_offset(void)
+{
+	u64 gtod, clock;
+
+	local_irq_disable();
+	gtod = ktime_get_ns();
+	clock = sched_clock();
+	__gtod_offset = (clock + __sched_clock_offset) - gtod;
+	local_irq_enable();
+}
+
+void sched_clock_init(void)
+{
+	/*
+	 * Set __gtod_offset such that once we mark sched_clock_running,
+	 * sched_clock_tick() continues where sched_clock() left off.
+	 *
+	 * Even if TSC is buggered, we're still UP at this point so it
+	 * can't really be out of sync.
+	 */
+	__sched_clock_gtod_offset();
+	barrier();
+	sched_clock_running = 1;
+}
+
 /*
  * We run this as late_initcall() such that it runs after all built-in drivers,
  * notably: acpi_processor and intel_idle, which can mark the TSC as unstable.
@@ -363,7 +383,7 @@ u64 sched_clock_cpu(int cpu)
 		return sched_clock() + __sched_clock_offset;
 
 	if (unlikely(!sched_clock_running))
-		return 0ull;
+		return sched_clock();
 
 	preempt_disable_notrace();
 	scd = cpu_sdc(cpu);
@@ -397,7 +417,6 @@ void sched_clock_tick(void)
 
 void sched_clock_tick_stable(void)
 {
-	u64 gtod, clock;
 
 	if (!sched_clock_stable())
 		return;
@@ -409,11 +428,7 @@ void sched_clock_tick_stable(void)
 	 * good moment to update our __gtod_offset. Because once we find the
 	 * TSC to be unstable, any computation will be computing crap.
 	 */
-	local_irq_disable();
-	gtod = ktime_get_ns();
-	clock = sched_clock();
-	__gtod_offset = (clock + __sched_clock_offset) - gtod;
-	local_irq_enable();
+	__sched_clock_gtod_offset();
 }
 
 /*
@@ -448,9 +463,6 @@ EXPORT_SYMBOL_GPL(sched_clock_idle_wakeup_event);
 
 u64 sched_clock_cpu(int cpu)
 {
-	if (unlikely(!sched_clock_running))
-		return 0;
-
 	return sched_clock();
 }
 

[toc] | [next] | [standalone]

#1740703

Hi Peter,

I am totally happy with removing notsc. This certainly simplifies the 
sched_clock code. Are there any issues with removing existing kernel 
parameters that I should be aware of?

Thank you,
Pasha

On 09/27/2017 09:10 AM, Peter Zijlstra wrote:
> On Wed, Sep 27, 2017 at 02:58:57PM +0200, Peter Zijlstra wrote:
>> (we're violating "notsc" in any case and really should kill that
>> option).
> 
> Something like so; in particular simple_udelay_calibrate() will issue
> RDTSC _way_ early, so there is absolutely no point in then pretending we
> can't use RDTSC for sched_clock.
> 

[toc] | [prev] | [next] | [standalone]

#1740753

Hi Pasha, Peter

At 09/27/2017 09:16 PM, Pasha Tatashin wrote:
> Hi Peter,
>
> I am totally happy with removing notsc. This certainly simplifies the
> sched_clock code. Are there any issues with removing existing kernel
> parameters that I should be aware of?
>

We do not want to do that. Because, we use "notsc" to support Dynamic
Reconfiguration[1].

AFAIK, this feature enables hot-add system board which contains CPUs
and memories. But the CPUs in different board may have different TSCs
which are not consistent with the TSC from the existing CPUs. If we 
hot-add a board directly, the machine may happen the inconsistency of
TSC.

We make our effort to specify the same TSC value as existing one through
hardware and firmware, but it is hard. So we recommend to specify
"notsc" option in command line for users who want to use Dynamic
Reconfiguration.

[1] 
http://www.fujitsu.com/global/products/computing/servers/mission-critical/primequest/technology/availability/dynamic-reconfiguration.html

Thanks,

	dou

> Thank you,
> Pasha
>
> On 09/27/2017 09:10 AM, Peter Zijlstra wrote:
>> On Wed, Sep 27, 2017 at 02:58:57PM +0200, Peter Zijlstra wrote:
>>> (we're violating "notsc" in any case and really should kill that
>>> option).
>>
>> Something like so; in particular simple_udelay_calibrate() will issue
>> RDTSC _way_ early, so there is absolutely no point in then pretending we
>> can't use RDTSC for sched_clock.
>>
>
>
>

[toc] | [prev] | [next] | [standalone]

#1740894

Hi Dou,

This makes sense. The current sched_clock_early() approach does not 
break it because with notsc TSC is used early in boot, and later 
stopped. But, notsc must stay.

Peter,

So, we could either expend sched_clock() with another static branch for 
early clock, or use what I proposed. IMO, the later is better, but 
either way works for me.

Thank you,
Pasha

On 09/27/2017 09:52 AM, Dou Liyang wrote:
> Hi Pasha, Peter
> 
> At 09/27/2017 09:16 PM, Pasha Tatashin wrote:
>> Hi Peter,
>>
>> I am totally happy with removing notsc. This certainly simplifies the
>> sched_clock code. Are there any issues with removing existing kernel
>> parameters that I should be aware of?
>>
> 
> We do not want to do that. Because, we use "notsc" to support Dynamic
> Reconfiguration[1].
> 
> AFAIK, this feature enables hot-add system board which contains CPUs
> and memories. But the CPUs in different board may have different TSCs
> which are not consistent with the TSC from the existing CPUs. If we 
> hot-add a board directly, the machine may happen the inconsistency of
> TSC.
> 
> We make our effort to specify the same TSC value as existing one through
> hardware and firmware, but it is hard. So we recommend to specify
> "notsc" option in command line for users who want to use Dynamic
> Reconfiguration.
> 
> [1] 
> http://www.fujitsu.com/global/products/computing/servers/mission-critical/primequest/technology/availability/dynamic-reconfiguration.html 
> 

[toc] | [prev] | [next] | [standalone]

#1740931

On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> We do not want to do that. Because, we use "notsc" to support Dynamic
> Reconfiguration[1].
> 
> AFAIK, this feature enables hot-add system board which contains CPUs
> and memories. But the CPUs in different board may have different TSCs
> which are not consistent with the TSC from the existing CPUs. If we hot-add
> a board directly, the machine may happen the inconsistency of
> TSC.
> 
> We make our effort to specify the same TSC value as existing one through
> hardware and firmware, but it is hard. So we recommend to specify
> "notsc" option in command line for users who want to use Dynamic
> Reconfiguration.

Oh gawd, that's horrific. And in my book a good reason to kill that
option.

[toc] | [prev] | [next] | [standalone]

#1740938

On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
> On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> > We do not want to do that. Because, we use "notsc" to support Dynamic
> > Reconfiguration[1].
> > 
> > AFAIK, this feature enables hot-add system board which contains CPUs
> > and memories. But the CPUs in different board may have different TSCs
> > which are not consistent with the TSC from the existing CPUs. If we hot-add
> > a board directly, the machine may happen the inconsistency of
> > TSC.
> > 
> > We make our effort to specify the same TSC value as existing one through
> > hardware and firmware, but it is hard. So we recommend to specify
> > "notsc" option in command line for users who want to use Dynamic
> > Reconfiguration.
> 
> Oh gawd, that's horrific. And in my book a good reason to kill that
> option.

That is, even with unsynchronized TSC we're better off using RDTSC. The
whole mess in kernel/sched/clock.c is all about getting semi sensible
results out of unsynchronized TSC.

There really is no reason to artificially kill TSC usage.

[toc] | [prev] | [next] | [standalone]

#1741378

Hi Peter,

At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
> On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
>> On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
>>> We do not want to do that. Because, we use "notsc" to support Dynamic
>>> Reconfiguration[1].
>>>
>>> AFAIK, this feature enables hot-add system board which contains CPUs
>>> and memories. But the CPUs in different board may have different TSCs
>>> which are not consistent with the TSC from the existing CPUs. If we hot-add
>>> a board directly, the machine may happen the inconsistency of
>>> TSC.
>>>
>>> We make our effort to specify the same TSC value as existing one through
>>> hardware and firmware, but it is hard. So we recommend to specify
>>> "notsc" option in command line for users who want to use Dynamic
>>> Reconfiguration.
>>
>> Oh gawd, that's horrific. And in my book a good reason to kill that
>> option.
>
> That is, even with unsynchronized TSC we're better off using RDTSC. The
> whole mess in kernel/sched/clock.c is all about getting semi sensible
> results out of unsynchronized TSC.
>

It will be best if we can support TSC sync capability in x86, but seems
is not easy.

Thanks,

	dou.

> There really is no reason to artificially kill TSC usage.
>
>
>

[toc] | [prev] | [next] | [standalone]

#1741470

On Thu, Sep 28, 2017 at 06:03:05PM +0800, Dou Liyang wrote:
> At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
> > On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
> > > On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> > > > We do not want to do that. Because, we use "notsc" to support Dynamic
> > > > Reconfiguration[1].
> > > > 
> > > > AFAIK, this feature enables hot-add system board which contains CPUs
> > > > and memories. But the CPUs in different board may have different TSCs
> > > > which are not consistent with the TSC from the existing CPUs. If we hot-add
> > > > a board directly, the machine may happen the inconsistency of
> > > > TSC.
> > > > 
> > > > We make our effort to specify the same TSC value as existing one through
> > > > hardware and firmware, but it is hard. So we recommend to specify
> > > > "notsc" option in command line for users who want to use Dynamic
> > > > Reconfiguration.
> > > 
> > > Oh gawd, that's horrific. And in my book a good reason to kill that
> > > option.
> > 
> > That is, even with unsynchronized TSC we're better off using RDTSC. The
> > whole mess in kernel/sched/clock.c is all about getting semi sensible
> > results out of unsynchronized TSC.
> > 
> 
> It will be best if we can support TSC sync capability in x86, but seems
> is not easy.

Sure, your hardware achieving sync would be best, but even if it does
not, we can still use TSC. Using notsc simple because you fail to sync
TSCs is quite crazy.

The thing is, we need to support unsync'ed TSC in any case, because
older chips (pre Nehalem) didn't have synchronized TSC in any case, and
it still happens on recent chips if the BIOS mucks it up, which happens
surprisingly often :-(

I would suggest you try your reconfigurable setup with "tsc=unstable"
and see if that works for you. That marks the TSC unconditionally
unstable at boot and avoids any further wobbles once the TSC watchdog
notices (although that too _should_ more or less work).

I do however hope you have a custom clocksource driver placed at higher
priority than the HPET.

[toc] | [prev] | [next] | [standalone]

#1741487

On Thu, 28 Sep 2017, Peter Zijlstra wrote:

> On Thu, Sep 28, 2017 at 06:03:05PM +0800, Dou Liyang wrote:
> > At 09/28/2017 02:09 AM, Peter Zijlstra wrote:
> > > On Wed, Sep 27, 2017 at 08:05:48PM +0200, Peter Zijlstra wrote:
> > > > On Wed, Sep 27, 2017 at 09:52:36PM +0800, Dou Liyang wrote:
> > > > > We do not want to do that. Because, we use "notsc" to support Dynamic
> > > > > Reconfiguration[1].
> > > > > 
> > > > > AFAIK, this feature enables hot-add system board which contains CPUs
> > > > > and memories. But the CPUs in different board may have different TSCs
> > > > > which are not consistent with the TSC from the existing CPUs. If we hot-add
> > > > > a board directly, the machine may happen the inconsistency of
> > > > > TSC.
> > > > > 
> > > > > We make our effort to specify the same TSC value as existing one through
> > > > > hardware and firmware, but it is hard. So we recommend to specify
> > > > > "notsc" option in command line for users who want to use Dynamic
> > > > > Reconfiguration.
> > > > 
> > > > Oh gawd, that's horrific. And in my book a good reason to kill that
> > > > option.
> > > 
> > > That is, even with unsynchronized TSC we're better off using RDTSC. The
> > > whole mess in kernel/sched/clock.c is all about getting semi sensible
> > > results out of unsynchronized TSC.
> > > 
> > 
> > It will be best if we can support TSC sync capability in x86, but seems
> > is not easy.
> 
> Sure, your hardware achieving sync would be best, but even if it does
> not, we can still use TSC. Using notsc simple because you fail to sync
> TSCs is quite crazy.
> 
> The thing is, we need to support unsync'ed TSC in any case, because
> older chips (pre Nehalem) didn't have synchronized TSC in any case, and
> it still happens on recent chips if the BIOS mucks it up, which happens
> surprisingly often :-(
> 
> I would suggest you try your reconfigurable setup with "tsc=unstable"
> and see if that works for you. That marks the TSC unconditionally
> unstable at boot and avoids any further wobbles once the TSC watchdog
> notices (although that too _should_ more or less work).

That should do the trick nicely and we might just end up converting notsc
to tsc=unstable silently so we can avoid the bike shed discussions about
removing it.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

#1741547

>>> It will be best if we can support TSC sync capability in x86, but seems
>>> is not easy.
>>
>> Sure, your hardware achieving sync would be best, but even if it does
>> not, we can still use TSC. Using notsc simple because you fail to sync
>> TSCs is quite crazy.
>>
>> The thing is, we need to support unsync'ed TSC in any case, because
>> older chips (pre Nehalem) didn't have synchronized TSC in any case, and
>> it still happens on recent chips if the BIOS mucks it up, which happens
>> surprisingly often :-(
>>
>> I would suggest you try your reconfigurable setup with "tsc=unstable"
>> and see if that works for you. That marks the TSC unconditionally
>> unstable at boot and avoids any further wobbles once the TSC watchdog
>> notices (although that too _should_ more or less work).
> 
> That should do the trick nicely and we might just end up converting notsc
> to tsc=unstable silently so we can avoid the bike shed discussions about
> removing it.
> 

Ok, I will start working on converting notsc to unstable, and modify my 
patches to do what Peter suggested earlier. In the mean time, I'd like 
to hear from Dou if this setup works with dynamic reconfig.

Thank you,
Pasha

[toc] | [prev] | [next] | [standalone]

#1742187

Hi, Pasha

At 09/28/2017 09:11 PM, Pasha Tatashin wrote:
>>>> It will be best if we can support TSC sync capability in x86, but seems
>>>> is not easy.
>>>
>>> Sure, your hardware achieving sync would be best, but even if it does
>>> not, we can still use TSC. Using notsc simple because you fail to sync
>>> TSCs is quite crazy.
>>>
>>> The thing is, we need to support unsync'ed TSC in any case, because
>>> older chips (pre Nehalem) didn't have synchronized TSC in any case, and
>>> it still happens on recent chips if the BIOS mucks it up, which happens
>>> surprisingly often :-(
>>>
>>> I would suggest you try your reconfigurable setup with "tsc=unstable"
>>> and see if that works for you. That marks the TSC unconditionally
>>> unstable at boot and avoids any further wobbles once the TSC watchdog
>>> notices (although that too _should_ more or less work).
>>
>> That should do the trick nicely and we might just end up converting notsc
>> to tsc=unstable silently so we can avoid the bike shed discussions about
>> removing it.
>>
>
> Ok, I will start working on converting notsc to unstable, and modify my
> patches to do what Peter suggested earlier. In the mean time, I'd like
> to hear from Dou if this setup works with dynamic reconfig.
>

OK, I will do it, But, October 1 is our national holiday, I will in 
holiday, and I just returned the test machine. :-(

May reply you in middle of the October.

Thanks,

	dou.

> Thank you,
> Pasha
>
>
>

[toc] | [prev] | [next] | [standalone]

#1740705

On Wed, Sep 27, 2017 at 02:58:57PM +0200, Peter Zijlstra wrote:
> (we're violating "notsc" in any case and really should kill that
> option).

Something like so; in particular simple_udelay_calibrate() will issue
RDTSC _way_ early, so there is absolutely no point in then pretending we
can't use RDTSC for sched_clock.

---

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 796d96bb0821..1dd3849a42ca 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -37,13 +37,6 @@ EXPORT_SYMBOL(tsc_khz);
  */
 static int __read_mostly tsc_unstable;
 
-/* native_sched_clock() is called before tsc_init(), so
-   we must start with the TSC soft disabled to prevent
-   erroneous rdtsc usage on !boot_cpu_has(X86_FEATURE_TSC) processors */
-static int __read_mostly tsc_disabled = -1;
-
-static DEFINE_STATIC_KEY_FALSE(__use_tsc);
-
 int tsc_clocksource_reliable;
 
 static u32 art_to_tsc_numerator;
@@ -191,24 +184,7 @@ static void set_cyc2ns_scale(unsigned long khz, int cpu, unsigned long long tsc_
  */
 u64 native_sched_clock(void)
 {
-	if (static_branch_likely(&__use_tsc)) {
-		u64 tsc_now = rdtsc();
-
-		/* return the value in ns */
-		return cycles_2_ns(tsc_now);
-	}
-
-	/*
-	 * Fall back to jiffies if there's no TSC available:
-	 * ( But note that we still use it if the TSC is marked
-	 *   unstable. We do this because unlike Time Of Day,
-	 *   the scheduler clock tolerates small errors and it's
-	 *   very important for it to be as fast as the platform
-	 *   can achieve it. )
-	 */
-
-	/* No locking but a rare wrong value is not a big deal: */
-	return (jiffies_64 - INITIAL_JIFFIES) * (1000000000 / HZ);
+	return cycles_2_ns(rdtsc());
 }
 
 /*
@@ -244,27 +220,6 @@ int check_tsc_unstable(void)
 }
 EXPORT_SYMBOL_GPL(check_tsc_unstable);
 
-#ifdef CONFIG_X86_TSC
-int __init notsc_setup(char *str)
-{
-	pr_warn("Kernel compiled with CONFIG_X86_TSC, cannot disable TSC completely\n");
-	tsc_disabled = 1;
-	return 1;
-}
-#else
-/*
- * disable flag for tsc. Takes effect by clearing the TSC cpu flag
- * in cpu/common.c
- */
-int __init notsc_setup(char *str)
-{
-	setup_clear_cpu_cap(X86_FEATURE_TSC);
-	return 1;
-}
-#endif
-
-__setup("notsc", notsc_setup);
-
 static int no_sched_irq_time;
 
 static int __init tsc_setup(char *str)
@@ -1229,7 +1184,7 @@ static void tsc_refine_calibration_work(struct work_struct *work)
 
 static int __init init_tsc_clocksource(void)
 {
-	if (!boot_cpu_has(X86_FEATURE_TSC) || tsc_disabled > 0 || !tsc_khz)
+	if (!boot_cpu_has(X86_FEATURE_TSC) || !tsc_khz)
 		return 0;
 
 	if (tsc_clocksource_reliable)
@@ -1311,14 +1266,6 @@ void __init tsc_init(void)
 		set_cyc2ns_scale(tsc_khz, cpu, cyc);
 	}
 
-	if (tsc_disabled > 0)
-		return;
-
-	/* now allow native_sched_clock() to use rdtsc */
-
-	tsc_disabled = 0;
-	static_branch_enable(&__use_tsc);
-
 	if (!no_sched_irq_time)
 		enable_sched_clock_irqtime();
 
@@ -1348,7 +1295,7 @@ unsigned long calibrate_delay_is_known(void)
 	int sibling, cpu = smp_processor_id();
 	struct cpumask *mask = topology_core_cpumask(cpu);
 
-	if (!tsc_disabled && !cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC))
+	if (!cpu_has(&cpu_data(cpu), X86_FEATURE_CONSTANT_TSC))
 		return 0;
 
 	if (!mask)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web