From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751274AbdCYN5Q (ORCPT ); Sat, 25 Mar 2017 09:57:16 -0400 Received: from aserp1040.oracle.com ([141.146.126.69]:49485 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbdCYN5O (ORCPT ); Sat, 25 Mar 2017 09:57:14 -0400 Subject: Re: [v2 0/9] Early boot time stamps for x86 To: Thomas Gleixner References: <1490368899-877997-1-git-send-email-pasha.tatashin@oracle.com> Cc: x86@kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, hpa@zytor.com From: Pasha Tatashin Message-ID: Date: Sat, 25 Mar 2017 09:55:36 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Thomas, The second versions was actually meant as a reply to your e-mail: the code differences were minimal: the main differences were in the cover letter. You mentioned that it is not necessary to have early boot time stamps, and I wanted to show examples how this data is useful to track scalability bugs and avoid future regressions. Anyway, you asked for some time to think about this problem, I won't send any replies to this thread for the next two weeks. So, please consider this solution. The feature is well abstracted, does not harm the performance of the fast path, and if necessary it can also be made optional with something like: CONFIG_HAVE_UNSTABLE_EARLY_CLOCK Thank you, Pasha On 03/25/2017 06:25 AM, Thomas Gleixner wrote: > On Fri, 24 Mar 2017, Pavel Tatashin wrote: > >> changelog >> --------- >> v1 - v2 >> In patch "x86/tsc: tsc early": >> - added tsc_adjusted_early() >> - fixed 32-bit compile error use do_div() > > Did you actually read my last reply on V1 of this? > > I made it entirely clear that the way this is done, i.e. hacking it into > the earliest boost stage is not going to happen. > > Further I asked you to hold off until I found some time to look into this > in detail. > > So what's the point of ignoring what I said and resending the whole lot > with some more hackery applied? > > I don't care about you wasting your time, but I very much care about my > time. > > Thanks, > > tglx > > > > > > >