From mboxrd@z Thu Jan 1 00:00:00 1970 From: "john stultz" Subject: Re: [RFC patch 15/15] LTTng timestamp x86 Date: Mon, 20 Oct 2008 14:38:37 -0700 Message-ID: <1f1b08da0810201438g6a109af5i75b34841462b655d@mail.gmail.com> References: <20081016232729.699004293@polymtl.ca> <20081016234657.837704867@polymtl.ca> <20081017012835.GA30195@Krystal> <57C9024A16AD2D4C97DC78E552063EA3532D455F@orsmsx505.amr.corp.intel.com> <20081017172515.GA9639@goodmis.org> <57C9024A16AD2D4C97DC78E552063EA3533458AC@orsmsx505.amr.corp.intel.com> <20081017184215.GB9874@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Return-path: Received: from mail-gx0-f16.google.com ([209.85.217.16]:63598 "EHLO mail-gx0-f16.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756458AbYJTVij (ORCPT ); Mon, 20 Oct 2008 17:38:39 -0400 Received: by gxk9 with SMTP id 9so4527532gxk.13 for ; Mon, 20 Oct 2008 14:38:38 -0700 (PDT) In-Reply-To: Content-Disposition: inline Sender: linux-arch-owner@vger.kernel.org List-ID: To: Linus Torvalds Cc: Mathieu Desnoyers , "Luck, Tony" , Steven Rostedt , Andrew Morton , Ingo Molnar , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , Peter Zijlstra , Thomas Gleixner , David Miller , Ingo Molnar , "H. Peter Anvin" On Mon, Oct 20, 2008 at 1:10 PM, Linus Torvalds wrote: > I think it's a mistake for us to maintain a single clock for > gettimeofday() (well, "getnstimeofday" and the whole "clocksource_read()" > crud to be technically correct). And sure, I bet clocksource_read() can do > various per-CPU things and try to do that, but it's complex and pretty > generic code, and as far as I know none of the clocksources have even > tried. The TSC clocksource read certainly does not (it just does a very > similar horrible "at least don't go backwards" crud that the LTTng patch > suggested). > > So I think we should make "xtime" be a per-CPU thing, and add support for > per-CPU clocksources. And screw that insane "mark_tsc_unstable()" thing. > > And if we did it well, we migth be able to get good timestamps that way > too. Personally I'd been hoping that the experiments in the trace timestamping code would provide a safe area of experimentation before we adapt it to the TSC clocksource implementation for getnstimeofday(). Earlier I know Andi and Jiri were working on such a per-cpu TSC clocksource, but I don't know where it ended up. I'm not quite sure I followed your per-cpu xtime thoughts. Could you explain further your thinking as to why the entire timekeeping subsystem should be per-cpu instead of just keeping that back in the arch-specific clocksource implementation? In other words, why keep things synced at the nanosecond level instead of keeping the per-cpu TSC synched at the cycle level? thanks -john