[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v2 3/6] x86/time: implement tsc as clocksource
>>> On 05.04.16 at 16:56, <joao.m.martins@xxxxxxxxxx> wrote: > On 04/05/2016 11:43 AM, Jan Beulich wrote: >>>>> On 29.03.16 at 15:44, <joao.m.martins@xxxxxxxxxx> wrote: >>> @@ -541,6 +613,10 @@ static int __init try_platform_timer(struct >>> platform_timesource *pts) >>> if ( rc <= 0 ) >>> return rc; >>> >>> + /* We have a platform timesource already so reset it */ >>> + if ( plt_src.counter_bits != 0 ) >>> + reset_platform_timer(); >> >> What if any of the time functions get used between here and the >> setting of the new clock source? For example, what will happen to >> log messages when "console_timestamps=..." is in effect? > time functions will use NOW() (i.e. get_s_time) which uses cpu_time structs > being updated on local_time_calibration() or cpu frequency changes. > reset_platform_timer() will zero out some of the variables used by the > plt_overflow and read_platform_stime(). The overflow and calibration isn't an > issue as the timers are previously killed so any further calls will use what's > on cpu_time while plt_src is being changed. > > The case I could see this being different is if cpu_frequency_change is called > between reset_platform_time() and the next update of stime_platform_stamp. In > this situation the calculation would end up a bit different meaning subsequent > calls of read_platform_stime() would return the equivalent to > scale_delta(plt_src->read_counter(), plt_scale), as opposed to computing with > a > previous taken stime_platform_stamp and incrementing a difference with a > counter > read. But can this situation actually happen? No matter which CPU freq model is being used (right now, may change when the Intel P-state driver finally arrives), Dom0 is required to be executing already, so no issue here. Since you didn't go into any detail on the specific example of log time stamps - am I to imply that they're completely unaffected by this (i.e. there's also no risk of them going backwards for a brief period of time)? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |