Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935637Ab3DHTGC (ORCPT ); Mon, 8 Apr 2013 15:06:02 -0400 Received: from mail-ob0-f170.google.com ([209.85.214.170]:37145 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934741Ab3DHTGA (ORCPT ); Mon, 8 Apr 2013 15:06:00 -0400 Message-ID: <51631510.6080401@linaro.org> Date: Mon, 08 Apr 2013 12:05:52 -0700 From: John Stultz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Pawel Moll CC: Richard Cochran , Peter Zijlstra , Stephane Eranian , David Ahern , Thomas Gleixner , LKML , "mingo@elte.hu" , Paul Mackerras , Anton Blanchard , Will Deacon , "ak@linux.intel.com" , Pekka Enberg , Steven Rostedt , Robert Richter Subject: Re: [RFC] perf: need to expose sched_clock to correlate user samples with kernel samples References: <51586315.7080006@gmail.com> <5159D221.70304@linaro.org> <1364889256.16858.1.camel@laptop> <515B0502.8070408@linaro.org> <1365009558.26858.19.camel@hornet> <515C66FE.7030501@linaro.org> <1365010502.26858.32.camel@hornet> <515C6C01.9070905@linaro.org> <1365092963.26858.107.camel@hornet> <1365185813.25942.12.camel@hornet> <20130406110507.GC7572@netboy> <1365443897.24306.12.camel@hornet> In-Reply-To: <1365443897.24306.12.camel@hornet> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1240 Lines: 33 On 04/08/2013 10:58 AM, Pawel Moll wrote: > Now, before I spend time doing all this, a question to John, Peter, > Stephane and the rest of the public - would a solution providing such > userspace interface: > > fd = sys_perf_open() > timestamp = clock_gettime((FD_TO_CLOCKID(fd), &ts) > > be acceptable to all? So thinking this through further, I'm worried we may _not_ be able to eventually enable this to be a vdso as I had earlier hoped. Mostly because I'm not sure how the fd -> file -> clock lookup could be done in userland (any ideas?). So this makes this approach mostly equivalent long term to the ioctl method, from a performance perspective. And makes the dynamic posix clockid somewhat less of a middle-ground compromise between the ioctl and generic constant clockid approach. So while I'm not opposed to the sort of extention proposed above, I want to make sure introducing the new approach is worth the effort when compared with just adding an ioctl. 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/