Messages in this thread | | | Date | Tue, 26 Jun 2018 07:27:05 -0400 | From | Pavel Tatashin <> | Subject | Re: [PATCH v12 10/11] sched: early boot clock |
| |
> > How's something like this? That moves sched_clock_init() to right before > we enable IRQs for the first time (which is after we've started the > whole timekeeping business). > > The thing is, sched_clock_init_late() reall is far too late, we need to > switch to unstable before we bring up SMP.
OK, sure.
> - sched_clock_postinit(); > + sched_clock_init();
Yes, we can move sched_clock_init(). But placing it after time_init() would work on all arches with unstable clock except for x86.
See comment above time_init x86: arch/x86/kernel/time.c
99/* 100 * Initialize TSC and delay the periodic timer init to 101 * late x86_late_time_init() so ioremap works. 102 */ 103void __init time_init(void) 104{ 105 late_time_init = x86_late_time_init; 106}
Only After this: > > late_time_init() > > x86_late_time_init() > > x86_init.timers.timer_init() > > hpet_time_init() Only after this call we finally start > > getting clock interrupts, and can get precise output from > > sched_clock_local().
We start getting timer interrupts. Is it acceptable to move sched_clock_init() after late_time_init()?
Thank you, Pavel
| |