Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751703AbbBMAZR (ORCPT ); Thu, 12 Feb 2015 19:25:17 -0500 Received: from mail-qg0-f48.google.com ([209.85.192.48]:34542 "EHLO mail-qg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751325AbbBMAZO (ORCPT ); Thu, 12 Feb 2015 19:25:14 -0500 MIME-Version: 1.0 In-Reply-To: <20150212153808.GR24151@twins.programming.kicks-ass.net> References: <1415292718-19785-2-git-send-email-pawel.moll@arm.com> <1421872037-12559-1-git-send-email-pawel.moll@arm.com> <1422895966.4944.25.camel@arm.com> <1422955245.4944.26.camel@arm.com> <20150211161256.GH2896@worktop.programming.kicks-ass.net> <54DC7AC6.5010605@intel.com> <20150212102814.GK2896@worktop.programming.kicks-ass.net> <20150212153808.GR24151@twins.programming.kicks-ass.net> Date: Fri, 13 Feb 2015 08:25:13 +0800 Message-ID: Subject: Re: [PATCH v5] perf: Use monotonic clock as a source for timestamps From: John Stultz To: Peter Zijlstra Cc: Adrian Hunter , Pawel Moll , ajh mls , Richard Cochran , Steven Rostedt , Ingo Molnar , Paul Mackerras , Arnaldo Carvalho de Melo , Masami Hiramatsu , Christopher Covington , Namhyung Kim , David Ahern , Thomas Gleixner , Tomeu Vizoso , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2071 Lines: 50 On Thu, Feb 12, 2015 at 11:38 PM, Peter Zijlstra wrote: > On Thu, Feb 12, 2015 at 11:28:14AM +0100, Peter Zijlstra wrote: >> > and you would have to check the clocksource is TSC. >> >> It implicitly does that; it has that sched_clock_stable() thing, but >> yeah I suppose someone could change the clocksource even though the tsc >> is stable. >> >> Not using TSC when its available is quite crazy though.. but sure. > > Something like this on top then.. it might have a few header issues, the > whole asm/tsc.h vs clocksource.h thing looks like pain. > > I haven't tried to compile it, maybe we can move cycle_t into types and > fwd declare struct clocksource or whatnot. > > Of course, all this is quite horrible on the timekeeping side; it might > be tglx and/or jstutlz are having spasms just reading it :-) Oof.. Yea, this exposes all sorts of timekeeping internals out to the rest of the kernel that I'd rather not have out there. > --- a/arch/x86/kernel/cpu/perf_event.c > +++ b/arch/x86/kernel/cpu/perf_event.c > @@ -1967,17 +1967,19 @@ static void local_clock_user_time(struct > cyc2ns_read_end(data); > } > > -extern void notrace __ktime_get_mono_fast(u64 *offset, u32 *mult, u16 *shift); > +extern bool notrace __ktime_get_mono_fast(cycle_t (*read)(struct clocksource *cs), > + u64 *offset, u32 *mult, u16 *shift); > > static void ktime_fast_mono_user_time(struct perf_event_mmap_page *userpg, u64 now) > { > + if (!__ktime_get_mono_fast(read_tsc, &userpg->time_zero, > + &userpg->time_mult, > + &userpg->time_shift)) Soo.. instead of hard-coding read_tsc here, can we instead use a clocksource flag that we can check that the current clocksource is valid for this sort of use? thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/