Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751533AbaLSRxs (ORCPT ); Fri, 19 Dec 2014 12:53:48 -0500 Received: from mail-la0-f54.google.com ([209.85.215.54]:46908 "EHLO mail-la0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751142AbaLSRxr (ORCPT ); Fri, 19 Dec 2014 12:53:47 -0500 MIME-Version: 1.0 In-Reply-To: <1419010969.13012.7@mail.thefacebook.com> References: <8559794d3a1924408a811a2881ab916fffb6015b.1418857018.git.shli@fb.com> <95a7ba1a95a6251439d5ca2d3d56fe7f0778cb95.1418857018.git.shli@fb.com> <20141219112350.GJ30905@twins.programming.kicks-ass.net> <1419010969.13012.7@mail.thefacebook.com> From: Andy Lutomirski Date: Fri, 19 Dec 2014 09:53:24 -0800 Message-ID: Subject: Re: [PATCH v2 3/3] X86: Add a thread cpu time implementation to vDSO To: Chris Mason Cc: Peter Zijlstra , Shaohua Li , "linux-kernel@vger.kernel.org" , X86 ML , Kernel-team@fb.com, "H. Peter Anvin" , Ingo Molnar , John Stultz Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Dec 19, 2014 at 9:42 AM, Chris Mason wrote: > > > On Fri, Dec 19, 2014 at 11:48 AM, Andy Lutomirski > wrote: >> >> On Fri, Dec 19, 2014 at 3:23 AM, Peter Zijlstra >> wrote: >>> >>> On Thu, Dec 18, 2014 at 04:22:59PM -0800, Andy Lutomirski wrote: >>>> >>>> Bad news: this patch is incorrect, I think. Take a look at >>>> update_rq_clock -- it does fancy things involving irq time and >>>> paravirt steal time. So this patch could result in extremely >>>> non-monotonic results. >>> >>> >>> Yeah, I'm not sure how (and if) we could make all that work :/ >> >> >> I obviously can't comment on what Facebook needs, but if I were >> rigging something up to profile my own code*, I'd want a count of >> elapsed time, including user, system, and probably interrupt as well. >> I would probably not want to count time during which I'm not >> scheduled, and I would also probably not want to count steal time. >> The latter makes any implementation kind of nasty. >> >> The API presumably doesn't need to be any particular clock id for >> clock_gettime, and it may not even need to be clock_gettime at all. >> >> Is perf self-monitoring good enough for this? If not, can we make it >> good enough? >> >> * I do this today using CLOCK_MONOTONIC > > > The clock_gettime calls are used for a wide variety of things, but usually > they are trying to instrument how much CPU the application is using. So for > example with the HHVM interpreter they have a ratio of the number of hhvm > instructions they were able to execute in N seconds of cputime. This gets > used to optimize the HHVM implementation and can be used as a push blocking > counter (code can't go in if it makes it slower). > > Wall time isn't a great representation of this because it includes factors > that might be outside a given HHVM patch, but it sounds like we're saying > almost the same thing. > > I'm not familiar with the perf self monitoring? You can call perf_event_open and mmap the result. Then you can read the docs^Wheader file. On the god side, it's an explicit mmap, so all the nasty preemption issues are entirely moot. And you can count cache misses and such if you want to be fancy. On the bad side, the docs are a bit weak, and the added context switch overhead might be higher. --Andy > > -chris > > > > -- Andy Lutomirski AMA Capital Management, LLC -- 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/