2008-05-03 20:29:28 +04:00
/*
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* sched_clock ( ) for unstable CPU clocks
2008-05-03 20:29:28 +04:00
*
2015-11-16 13:08:45 +03:00
* Copyright ( C ) 2008 Red Hat , Inc . , Peter Zijlstra
2008-05-03 20:29:28 +04:00
*
2008-07-09 08:15:33 +04:00
* Updates and enhancements :
* Copyright ( C ) 2008 Red Hat , Inc . Steven Rostedt < srostedt @ redhat . com >
*
2008-05-03 20:29:28 +04:00
* Based on code by :
* Ingo Molnar < mingo @ redhat . com >
* Guillaume Chazarain < guichaz @ gmail . com >
*
2010-05-25 12:48:51 +04:00
*
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* What this file implements :
2010-05-25 12:48:51 +04:00
*
* cpu_clock ( i ) provides a fast ( execution time ) high resolution
* clock with bounded drift between CPUs . The value of cpu_clock ( i )
* is monotonic for constant i . The timestamp returned is in nanoseconds .
*
* # # # # # # # # # # # # # # # # # # # # # # # # # BIG FAT WARNING # # # # # # # # # # # # # # # # # # # # # # # # # #
* # when comparing cpu_clock ( i ) to cpu_clock ( j ) for i ! = j , time can #
* # go backwards ! ! #
* # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
*
* There is no strict promise about the base , although it tends to start
* at 0 on boot ( but people really shouldn ' t rely on that ) .
*
* cpu_clock ( i ) - - can be used from any context , including NMI .
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* local_clock ( ) - - is cpu_clock ( ) on the current CPU .
2010-05-25 12:48:51 +04:00
*
2013-11-28 22:31:23 +04:00
* sched_clock_cpu ( i )
*
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* How it is implemented :
2010-05-25 12:48:51 +04:00
*
* The implementation either uses sched_clock ( ) when
* ! CONFIG_HAVE_UNSTABLE_SCHED_CLOCK , which means in that case the
* sched_clock ( ) is assumed to provide these properties ( mostly it means
* the architecture provides a globally synchronized highres time source ) .
*
* Otherwise it tries to create a semi stable clock from a mixture of other
* clocks , including :
*
* - GTOD ( clock monotomic )
2008-05-03 20:29:28 +04:00
* - sched_clock ( )
* - explicit idle events
*
2010-05-25 12:48:51 +04:00
* We use GTOD as base and use sched_clock ( ) deltas to improve resolution . The
* deltas are filtered to provide monotonicity and keeping it within an
* expected window .
2008-05-03 20:29:28 +04:00
*
* Furthermore , explicit sleep and wakeup hooks allow us to account for time
* that is otherwise invisible ( TSC gets stopped ) .
*
*/
2018-03-03 14:20:47 +03:00
# include "sched.h"
2018-07-19 23:55:41 +03:00
# include <linux/sched_clock.h>
2008-05-03 20:29:28 +04:00
2008-07-25 22:45:00 +04:00
/*
* Scheduler clock - returns current time in nanosec units .
* This is default implementation .
* Architectures and sub - architectures can override this .
*/
2014-04-08 02:39:20 +04:00
unsigned long long __weak sched_clock ( void )
2008-07-25 22:45:00 +04:00
{
2009-05-08 17:24:49 +04:00
return ( unsigned long long ) ( jiffies - INITIAL_JIFFIES )
* ( NSEC_PER_SEC / HZ ) ;
2008-07-25 22:45:00 +04:00
}
2010-04-15 10:54:59 +04:00
EXPORT_SYMBOL_GPL ( sched_clock ) ;
2008-05-03 20:29:28 +04:00
2018-07-19 23:55:43 +03:00
static DEFINE_STATIC_KEY_FALSE ( sched_clock_running ) ;
2008-08-11 10:59:03 +04:00
2008-05-03 20:29:28 +04:00
# ifdef CONFIG_HAVE_UNSTABLE_SCHED_CLOCK
2017-01-19 16:36:33 +03:00
/*
* We must start with ! __sched_clock_stable because the unstable - > stable
* transition is accurate , while the stable - > unstable transition is not .
*
* Similarly we start with __sched_clock_stable_early , thereby assuming we
* will become stable , such that there ' s only a single 1 - > 0 transition .
*/
2016-12-15 15:21:58 +03:00
static DEFINE_STATIC_KEY_FALSE ( __sched_clock_stable ) ;
2017-01-19 16:36:33 +03:00
static int __sched_clock_stable_early = 1 ;
2013-11-28 22:38:42 +04:00
2016-12-15 15:36:17 +03:00
/*
2017-03-17 14:48:18 +03:00
* We want : ktime_get_ns ( ) + __gtod_offset = = sched_clock ( ) + __sched_clock_offset
2016-12-15 15:36:17 +03:00
*/
2017-03-17 14:48:18 +03:00
__read_mostly u64 __sched_clock_offset ;
static __read_mostly u64 __gtod_offset ;
2016-12-15 15:36:17 +03:00
struct sched_clock_data {
u64 tick_raw ;
u64 tick_gtod ;
u64 clock ;
} ;
static DEFINE_PER_CPU_SHARED_ALIGNED ( struct sched_clock_data , sched_clock_data ) ;
static inline struct sched_clock_data * this_scd ( void )
{
return this_cpu_ptr ( & sched_clock_data ) ;
}
static inline struct sched_clock_data * cpu_sdc ( int cpu )
{
return & per_cpu ( sched_clock_data , cpu ) ;
}
2013-11-28 22:38:42 +04:00
int sched_clock_stable ( void )
{
2016-12-15 15:21:58 +03:00
return static_branch_likely ( & __sched_clock_stable ) ;
2013-11-28 22:38:42 +04:00
}
2017-04-21 13:11:53 +03:00
static void __scd_stamp ( struct sched_clock_data * scd )
{
scd - > tick_gtod = ktime_get_ns ( ) ;
scd - > tick_raw = sched_clock ( ) ;
}
2014-01-22 15:59:18 +04:00
static void __set_sched_clock_stable ( void )
2013-11-28 22:38:42 +04:00
{
2017-05-24 09:52:02 +03:00
struct sched_clock_data * scd ;
2016-12-15 15:36:17 +03:00
2017-05-24 09:52:02 +03:00
/*
* Since we ' re still unstable and the tick is already running , we have
* to disable IRQs in order to get a consistent scd - > tick * reading .
*/
local_irq_disable ( ) ;
scd = this_scd ( ) ;
2016-12-15 15:36:17 +03:00
/*
* Attempt to make the ( initial ) unstable - > stable transition continuous .
*/
2017-03-17 14:48:18 +03:00
__sched_clock_offset = ( scd - > tick_gtod + __gtod_offset ) - ( scd - > tick_raw ) ;
2017-05-24 09:52:02 +03:00
local_irq_enable ( ) ;
2016-12-15 15:36:17 +03:00
printk ( KERN_INFO " sched_clock: Marking stable (%lld, %lld)->(%lld, %lld) \n " ,
2017-03-17 14:48:18 +03:00
scd - > tick_gtod , __gtod_offset ,
scd - > tick_raw , __sched_clock_offset ) ;
2016-12-15 15:36:17 +03:00
2016-12-15 15:21:58 +03:00
static_branch_enable ( & __sched_clock_stable ) ;
2015-07-22 18:03:52 +03:00
tick_dep_clear ( TICK_DEP_BIT_CLOCK_UNSTABLE ) ;
2014-01-22 15:59:18 +04:00
}
2017-04-21 13:11:53 +03:00
/*
* If we ever get here , we ' re screwed , because we found out - - typically after
* the fact - - that TSC wasn ' t good . This means all our clocksources ( including
* ktime ) could have reported wrong values .
*
* What we do here is an attempt to fix up and continue sort of where we left
* off in a coherent manner .
*
* The only way to fully avoid random clock jumps is to boot with :
* " tsc=unstable " .
*/
2017-03-13 15:46:21 +03:00
static void __sched_clock_work ( struct work_struct * work )
{
2017-04-21 13:11:53 +03:00
struct sched_clock_data * scd ;
int cpu ;
/* take a current timestamp and set 'now' */
preempt_disable ( ) ;
scd = this_scd ( ) ;
__scd_stamp ( scd ) ;
scd - > clock = scd - > tick_gtod + __gtod_offset ;
preempt_enable ( ) ;
/* clone to all CPUs */
for_each_possible_cpu ( cpu )
per_cpu ( sched_clock_data , cpu ) = * scd ;
2017-04-21 13:52:52 +03:00
printk ( KERN_WARNING " TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. \n " ) ;
2017-04-21 13:11:53 +03:00
printk ( KERN_INFO " sched_clock: Marking unstable (%lld, %lld)<-(%lld, %lld) \n " ,
scd - > tick_gtod , __gtod_offset ,
scd - > tick_raw , __sched_clock_offset ) ;
2017-03-13 15:46:21 +03:00
static_branch_disable ( & __sched_clock_stable ) ;
}
static DECLARE_WORK ( sched_clock_work , __sched_clock_work ) ;
static void __clear_sched_clock_stable ( void )
2013-11-28 22:38:42 +04:00
{
2017-04-21 13:11:53 +03:00
if ( ! sched_clock_stable ( ) )
return ;
2016-12-15 15:36:17 +03:00
2015-07-22 18:03:52 +03:00
tick_dep_set ( TICK_DEP_BIT_CLOCK_UNSTABLE ) ;
2017-04-21 13:11:53 +03:00
schedule_work ( & sched_clock_work ) ;
2017-03-13 15:46:21 +03:00
}
2013-12-11 21:55:53 +04:00
void clear_sched_clock_stable ( void )
{
2014-01-22 15:59:18 +04:00
__sched_clock_stable_early = 0 ;
2016-12-15 15:35:52 +03:00
smp_mb ( ) ; /* matches sched_clock_init_late() */
2014-01-22 15:59:18 +04:00
2018-07-19 23:55:43 +03:00
if ( static_key_count ( & sched_clock_running . key ) = = 2 )
2017-03-13 15:46:21 +03:00
__clear_sched_clock_stable ( ) ;
2013-12-11 21:55:53 +04:00
}
2018-07-19 23:55:41 +03:00
static void __sched_clock_gtod_offset ( void )
{
2018-07-20 11:09:11 +03:00
struct sched_clock_data * scd = this_scd ( ) ;
__scd_stamp ( scd ) ;
__gtod_offset = ( scd - > tick_raw + __sched_clock_offset ) - scd - > tick_gtod ;
2018-07-19 23:55:41 +03:00
}
void __init sched_clock_init ( void )
{
2018-07-19 23:55:42 +03:00
/*
* 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 .
*/
2018-07-20 11:09:11 +03:00
local_irq_disable ( ) ;
2018-07-19 23:55:42 +03:00
__sched_clock_gtod_offset ( ) ;
2018-07-20 11:09:11 +03:00
local_irq_enable ( ) ;
2018-07-19 23:55:42 +03:00
2018-07-19 23:55:43 +03:00
static_branch_inc ( & sched_clock_running ) ;
2018-07-19 23:55:41 +03:00
}
2017-04-21 13:46:57 +03:00
/*
* 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 .
*/
static int __init sched_clock_init_late ( void )
2008-05-03 20:29:28 +04:00
{
2018-07-19 23:55:43 +03:00
static_branch_inc ( & sched_clock_running ) ;
2014-01-22 15:59:18 +04:00
/*
* Ensure that it is impossible to not do a static_key update .
*
* Either { set , clear } _sched_clock_stable ( ) must see sched_clock_running
* and do the update , or we must see their __sched_clock_stable_early
* and do the update , or both .
*/
smp_mb ( ) ; /* matches {set,clear}_sched_clock_stable() */
if ( __sched_clock_stable_early )
__set_sched_clock_stable ( ) ;
2017-04-21 13:46:57 +03:00
return 0 ;
2008-05-03 20:29:28 +04:00
}
2017-04-21 13:46:57 +03:00
late_initcall ( sched_clock_init_late ) ;
2008-05-03 20:29:28 +04:00
2008-08-25 19:15:34 +04:00
/*
2009-02-26 22:20:29 +03:00
* min , max except they take wrapping into account
2008-08-25 19:15:34 +04:00
*/
static inline u64 wrap_min ( u64 x , u64 y )
{
return ( s64 ) ( x - y ) < 0 ? x : y ;
}
static inline u64 wrap_max ( u64 x , u64 y )
{
return ( s64 ) ( x - y ) > 0 ? x : y ;
}
2008-05-03 20:29:28 +04:00
/*
* update the percpu scd from the raw @ now value
*
* - filter out backward motion
2008-08-25 19:15:34 +04:00
* - use the GTOD tick value to create a window to filter crazy TSC values
2008-05-03 20:29:28 +04:00
*/
2009-09-18 22:14:01 +04:00
static u64 sched_clock_local ( struct sched_clock_data * scd )
2008-05-03 20:29:28 +04:00
{
2017-03-22 23:24:17 +03:00
u64 now , clock , old_clock , min_clock , max_clock , gtod ;
2009-09-18 22:14:01 +04:00
s64 delta ;
2008-05-03 20:29:28 +04:00
2009-09-18 22:14:01 +04:00
again :
now = sched_clock ( ) ;
delta = now - scd - > tick_raw ;
2008-08-25 19:15:34 +04:00
if ( unlikely ( delta < 0 ) )
delta = 0 ;
2008-05-03 20:29:28 +04:00
2009-09-18 22:14:01 +04:00
old_clock = scd - > clock ;
2008-08-25 19:15:34 +04:00
/*
* scd - > clock = clamp ( scd - > tick_gtod + delta ,
2009-02-26 22:20:29 +03:00
* max ( scd - > tick_gtod , scd - > clock ) ,
* scd - > tick_gtod + TICK_NSEC ) ;
2008-08-25 19:15:34 +04:00
*/
2008-05-03 20:29:28 +04:00
2017-03-22 23:24:17 +03:00
gtod = scd - > tick_gtod + __gtod_offset ;
clock = gtod + delta ;
min_clock = wrap_max ( gtod , old_clock ) ;
max_clock = wrap_max ( old_clock , gtod + TICK_NSEC ) ;
2008-05-03 20:29:28 +04:00
2008-08-25 19:15:34 +04:00
clock = wrap_max ( clock , min_clock ) ;
clock = wrap_min ( clock , max_clock ) ;
2008-05-03 20:29:28 +04:00
2009-09-30 22:36:19 +04:00
if ( cmpxchg64 ( & scd - > clock , old_clock , clock ) ! = old_clock )
2009-09-18 22:14:01 +04:00
goto again ;
2008-07-30 12:15:55 +04:00
2009-09-18 22:14:01 +04:00
return clock ;
2008-05-03 20:29:28 +04:00
}
2009-09-18 22:14:01 +04:00
static u64 sched_clock_remote ( struct sched_clock_data * scd )
2008-05-03 20:29:28 +04:00
{
2009-09-18 22:14:01 +04:00
struct sched_clock_data * my_scd = this_scd ( ) ;
u64 this_clock , remote_clock ;
u64 * ptr , old_val , val ;
sched_clock: Prevent 64bit inatomicity on 32bit systems
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2013-04-06 12:10:27 +04:00
# if BITS_PER_LONG != 64
again :
/*
* Careful here : The local and the remote clock values need to
* be read out atomic as we need to compare the values and
* then update either the local or the remote side . So the
* cmpxchg64 below only protects one readout .
*
* We must reread via sched_clock_local ( ) in the retry case on
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* 32 - bit kernels as an NMI could use sched_clock_local ( ) via the
sched_clock: Prevent 64bit inatomicity on 32bit systems
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2013-04-06 12:10:27 +04:00
* tracer and hit between the readout of
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* the low 32 - bit and the high 32 - bit portion .
sched_clock: Prevent 64bit inatomicity on 32bit systems
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2013-04-06 12:10:27 +04:00
*/
this_clock = sched_clock_local ( my_scd ) ;
/*
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* We must enforce atomic readout on 32 - bit , otherwise the
* update on the remote CPU can hit inbetween the readout of
* the low 32 - bit and the high 32 - bit portion .
sched_clock: Prevent 64bit inatomicity on 32bit systems
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2013-04-06 12:10:27 +04:00
*/
remote_clock = cmpxchg64 ( & scd - > clock , 0 , 0 ) ;
# else
/*
sched: Clean up and harmonize the coding style of the scheduler code base
A good number of small style inconsistencies have accumulated
in the scheduler core, so do a pass over them to harmonize
all these details:
- fix speling in comments,
- use curly braces for multi-line statements,
- remove unnecessary parentheses from integer literals,
- capitalize consistently,
- remove stray newlines,
- add comments where necessary,
- remove invalid/unnecessary comments,
- align structure definitions and other data types vertically,
- add missing newlines for increased readability,
- fix vertical tabulation where it's misaligned,
- harmonize preprocessor conditional block labeling
and vertical alignment,
- remove line-breaks where they uglify the code,
- add newline after local variable definitions,
No change in functionality:
md5:
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.before.asm
1191fa0a890cfa8132156d2959d7e9e2 built-in.o.after.asm
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Mike Galbraith <efault@gmx.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
2018-03-03 16:01:12 +03:00
* On 64 - bit kernels the read of [ my ] scd - > clock is atomic versus the
* update , so we can avoid the above 32 - bit dance .
sched_clock: Prevent 64bit inatomicity on 32bit systems
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2013-04-06 12:10:27 +04:00
*/
2009-09-18 22:14:01 +04:00
sched_clock_local ( my_scd ) ;
again :
this_clock = my_scd - > clock ;
remote_clock = scd - > clock ;
sched_clock: Prevent 64bit inatomicity on 32bit systems
The sched_clock_remote() implementation has the following inatomicity
problem on 32bit systems when accessing the remote scd->clock, which
is a 64bit value.
CPU0 CPU1
sched_clock_local() sched_clock_remote(CPU0)
...
remote_clock = scd[CPU0]->clock
read_low32bit(scd[CPU0]->clock)
cmpxchg64(scd->clock,...)
read_high32bit(scd[CPU0]->clock)
While the update of scd->clock is using an atomic64 mechanism, the
readout on the remote cpu is not, which can cause completely bogus
readouts.
It is a quite rare problem, because it requires the update to hit the
narrow race window between the low/high readout and the update must go
across the 32bit boundary.
The resulting misbehaviour is, that CPU1 will see the sched_clock on
CPU1 ~4 seconds ahead of it's own and update CPU1s sched_clock value
to this bogus timestamp. This stays that way due to the clamping
implementation for about 4 seconds until the synchronization with
CLOCK_MONOTONIC undoes the problem.
The issue is hard to observe, because it might only result in a less
accurate SCHED_OTHER timeslicing behaviour. To create observable
damage on realtime scheduling classes, it is necessary that the bogus
update of CPU1 sched_clock happens in the context of an realtime
thread, which then gets charged 4 seconds of RT runtime, which results
in the RT throttler mechanism to trigger and prevent scheduling of RT
tasks for a little less than 4 seconds. So this is quite unlikely as
well.
The issue was quite hard to decode as the reproduction time is between
2 days and 3 weeks and intrusive tracing makes it less likely, but the
following trace recorded with trace_clock=global, which uses
sched_clock_local(), gave the final hint:
<idle>-0 0d..30 400269.477150: hrtimer_cancel: hrtimer=0xf7061e80
<idle>-0 0d..30 400269.477151: hrtimer_start: hrtimer=0xf7061e80 ...
irq/20-S-587 1d..32 400273.772118: sched_wakeup: comm= ... target_cpu=0
<idle>-0 0dN.30 400273.772118: hrtimer_cancel: hrtimer=0xf7061e80
What happens is that CPU0 goes idle and invokes
sched_clock_idle_sleep_event() which invokes sched_clock_local() and
CPU1 runs a remote wakeup for CPU0 at the same time, which invokes
sched_remote_clock(). The time jump gets propagated to CPU0 via
sched_remote_clock() and stays stale on both cores for ~4 seconds.
There are only two other possibilities, which could cause a stale
sched clock:
1) ktime_get() which reads out CLOCK_MONOTONIC returns a sporadic
wrong value.
2) sched_clock() which reads the TSC returns a sporadic wrong value.
#1 can be excluded because sched_clock would continue to increase for
one jiffy and then go stale.
#2 can be excluded because it would not make the clock jump
forward. It would just result in a stale sched_clock for one jiffy.
After quite some brain twisting and finding the same pattern on other
traces, sched_clock_remote() remained the only place which could cause
such a problem and as explained above it's indeed racy on 32bit
systems.
So while on 64bit systems the readout is atomic, we need to verify the
remote readout on 32bit machines. We need to protect the local->clock
readout in sched_clock_remote() on 32bit as well because an NMI could
hit between the low and the high readout, call sched_clock_local() and
modify local->clock.
Thanks to Siegfried Wulsch for bearing with my debug requests and
going through the tedious tasks of running a bunch of reproducer
systems to generate the debug information which let me decode the
issue.
Reported-by: Siegfried Wulsch <Siegfried.Wulsch@rovema.de>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/alpine.LFD.2.02.1304051544160.21884@ionos
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: stable@vger.kernel.org
2013-04-06 12:10:27 +04:00
# endif
2009-09-18 22:14:01 +04:00
/*
* Use the opportunity that we have both locks
* taken to couple the two clocks : we take the
* larger time as the latest time for both
* runqueues . ( this creates monotonic movement )
*/
if ( likely ( ( s64 ) ( remote_clock - this_clock ) < 0 ) ) {
ptr = & scd - > clock ;
old_val = remote_clock ;
val = this_clock ;
2008-05-03 20:29:28 +04:00
} else {
2009-09-18 22:14:01 +04:00
/*
* Should be rare , but possible :
*/
ptr = & my_scd - > clock ;
old_val = this_clock ;
val = remote_clock ;
2008-05-03 20:29:28 +04:00
}
2009-09-18 22:14:01 +04:00
2009-09-30 22:36:19 +04:00
if ( cmpxchg64 ( ptr , old_val , val ) ! = old_val )
2009-09-18 22:14:01 +04:00
goto again ;
return val ;
2008-05-03 20:29:28 +04:00
}
2010-05-25 12:48:51 +04:00
/*
* Similar to cpu_clock ( ) , but requires local IRQs to be disabled .
*
* See cpu_clock ( ) .
*/
2008-05-03 20:29:28 +04:00
u64 sched_clock_cpu ( int cpu )
{
2009-02-26 22:20:29 +03:00
struct sched_clock_data * scd ;
2009-09-18 22:14:01 +04:00
u64 clock ;
2013-11-28 22:38:42 +04:00
if ( sched_clock_stable ( ) )
2017-03-17 14:48:18 +03:00
return sched_clock ( ) + __sched_clock_offset ;
2008-05-29 12:07:15 +04:00
2018-07-19 23:55:43 +03:00
if ( ! static_branch_unlikely ( & sched_clock_running ) )
2018-07-19 23:55:42 +03:00
return sched_clock ( ) ;
2008-05-29 12:07:15 +04:00
2014-03-06 09:25:28 +04:00
preempt_disable_notrace ( ) ;
2009-09-18 22:14:01 +04:00
scd = cpu_sdc ( cpu ) ;
2008-05-03 20:29:28 +04:00
2009-09-18 22:14:01 +04:00
if ( cpu ! = smp_processor_id ( ) )
clock = sched_clock_remote ( scd ) ;
else
clock = sched_clock_local ( scd ) ;
2014-03-06 09:25:28 +04:00
preempt_enable_notrace ( ) ;
2008-04-14 10:50:02 +04:00
2008-05-03 20:29:28 +04:00
return clock ;
}
2016-04-11 17:38:34 +03:00
EXPORT_SYMBOL_GPL ( sched_clock_cpu ) ;
2008-05-03 20:29:28 +04:00
void sched_clock_tick ( void )
{
2009-02-26 23:40:16 +03:00
struct sched_clock_data * scd ;
2008-05-29 12:07:15 +04:00
2017-04-21 13:14:13 +03:00
if ( sched_clock_stable ( ) )
return ;
2018-07-19 23:55:43 +03:00
if ( ! static_branch_unlikely ( & sched_clock_running ) )
2017-04-21 13:14:13 +03:00
return ;
2017-11-06 18:01:27 +03:00
lockdep_assert_irqs_disabled ( ) ;
2008-05-03 20:29:28 +04:00
2009-02-26 23:40:16 +03:00
scd = this_scd ( ) ;
2017-04-21 13:11:53 +03:00
__scd_stamp ( scd ) ;
2017-04-21 13:14:13 +03:00
sched_clock_local ( scd ) ;
}
void sched_clock_tick_stable ( void )
{
if ( ! sched_clock_stable ( ) )
return ;
/*
* Called under watchdog_lock .
*
* The watchdog just found this TSC to ( still ) be stable , so now is a
* 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 ( ) ;
2018-07-19 23:55:41 +03:00
__sched_clock_gtod_offset ( ) ;
2017-04-21 13:14:13 +03:00
local_irq_enable ( ) ;
2008-05-03 20:29:28 +04:00
}
/*
* We are going deep - idle ( irqs are disabled ) :
*/
void sched_clock_idle_sleep_event ( void )
{
sched_clock_cpu ( smp_processor_id ( ) ) ;
}
EXPORT_SYMBOL_GPL ( sched_clock_idle_sleep_event ) ;
/*
2017-04-21 13:43:59 +03:00
* We just idled ; resync with ktime .
2008-05-03 20:29:28 +04:00
*/
2017-04-21 13:26:23 +03:00
void sched_clock_idle_wakeup_event ( void )
2008-05-03 20:29:28 +04:00
{
2017-04-21 13:43:59 +03:00
unsigned long flags ;
if ( sched_clock_stable ( ) )
return ;
if ( unlikely ( timekeeping_suspended ) )
2008-12-23 01:05:28 +03:00
return ;
2017-04-21 13:43:59 +03:00
local_irq_save ( flags ) ;
2008-08-25 19:15:34 +04:00
sched_clock_tick ( ) ;
2017-04-21 13:43:59 +03:00
local_irq_restore ( flags ) ;
2008-05-03 20:29:28 +04:00
}
EXPORT_SYMBOL_GPL ( sched_clock_idle_wakeup_event ) ;
2009-02-26 23:40:16 +03:00
# else /* CONFIG_HAVE_UNSTABLE_SCHED_CLOCK */
2018-07-19 23:55:41 +03:00
void __init sched_clock_init ( void )
{
2018-07-19 23:55:43 +03:00
static_branch_inc ( & sched_clock_running ) ;
2018-07-30 16:52:52 +03:00
local_irq_disable ( ) ;
2018-07-19 23:55:41 +03:00
generic_sched_clock_init ( ) ;
2018-07-30 16:52:52 +03:00
local_irq_enable ( ) ;
2018-07-19 23:55:41 +03:00
}
2009-02-26 23:40:16 +03:00
u64 sched_clock_cpu ( int cpu )
{
2018-07-19 23:55:43 +03:00
if ( ! static_branch_unlikely ( & sched_clock_running ) )
2009-02-26 23:40:16 +03:00
return 0 ;
return sched_clock ( ) ;
}
2016-12-15 15:35:52 +03:00
2009-12-14 05:25:02 +03:00
# endif /* CONFIG_HAVE_UNSTABLE_SCHED_CLOCK */
2008-06-27 15:41:15 +04:00
2015-02-13 02:01:24 +03:00
/*
* Running clock - returns the time that has elapsed while a guest has been
* running .
* On a guest this value should be local_clock minus the time the guest was
* suspended by the hypervisor ( for any reason ) .
* On bare metal this function should return the same as local_clock .
* Architectures and sub - architectures can override this .
*/
u64 __weak running_clock ( void )
{
return local_clock ( ) ;
}