Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751144AbaK0PGC (ORCPT ); Thu, 27 Nov 2014 10:06:02 -0500 Received: from foss-mx-na.foss.arm.com ([217.140.108.86]:40785 "EHLO foss-mx-na.foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750784AbaK0PGA (ORCPT ); Thu, 27 Nov 2014 10:06:00 -0500 Message-ID: <1417100750.4371.1.camel@arm.com> Subject: Re: [PATCH v4 1/3] perf: Use monotonic clock as a source for timestamps From: Pawel Moll To: Ingo Molnar , Peter Zijlstra Cc: Richard Cochran , Steven Rostedt , Paul Mackerras , Arnaldo Carvalho de Melo , John Stultz , Masami Hiramatsu , Christopher Covington , Namhyung Kim , David Ahern , Thomas Gleixner , Tomeu Vizoso , "linux-kernel@vger.kernel.org" , "linux-api@vger.kernel.org" Date: Thu, 27 Nov 2014 15:05:50 +0000 In-Reply-To: <1415292718-19785-2-git-send-email-pawel.moll@arm.com> References: <1415292718-19785-1-git-send-email-pawel.moll@arm.com> <1415292718-19785-2-git-send-email-pawel.moll@arm.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.12.7-0ubuntu1 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2014-11-06 at 16:51 +0000, Pawel Moll wrote: > Until now, perf framework never defined the meaning of the timestamps > captured as PERF_SAMPLE_TIME sample type. The values were obtaining > from local (sched) clock, which is unavailable in userspace. This made > it impossible to correlate perf data with any other events. Other > tracing solutions have the source configurable (ftrace) or just share > a common time domain between kernel and userspace (LTTng). > > Follow the trend by using monotonic clock, which is readily available > as POSIX CLOCK_MONOTONIC. > > Also add a sysctl "perf_sample_time_clk_id" attribute which can be used > by the user to obtain the clk_id to be used with POSIX clock API (eg. > clock_gettime()) to obtain a time value comparable with perf samples. > > Old behaviour can be restored by using "perf_use_local_clock" kernel > parameter. > > Signed-off-by: Pawel Moll It's been 3 weeks without any negative feedback (no feedback at all, but I take the optimistic view :-)... How about queuing at least this patch alone for the incoming merge window? Or at least getting it into -next, with the view at 3.20? Pawel -- 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/