From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753908AbbJ0VpH (ORCPT ); Tue, 27 Oct 2015 17:45:07 -0400 Received: from mail-io0-f177.google.com ([209.85.223.177]:34433 "EHLO mail-io0-f177.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751281AbbJ0VpD (ORCPT ); Tue, 27 Oct 2015 17:45:03 -0400 Message-ID: <562FF05A.508@gmail.com> Date: Tue, 27 Oct 2015 14:44:58 -0700 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Leonid Yegoshin CC: Ralf Baechle , Markos Chandras , linux-mips@linux-mips.org, Alex Smith , linux-kernel@vger.kernel.org Subject: Re: [v3, 3/3] MIPS: VDSO: Add implementations of gettimeofday() and clock_gettime() References: <1445417864-31453-1-git-send-email-markos.chandras@imgtec.com> <5629904A.2070400@imgtec.com> <20151027144748.GA23785@linux-mips.org> <562FE29C.8040106@imgtec.com> <562FE678.2030307@gmail.com> <562FE96C.3070002@imgtec.com> In-Reply-To: <562FE96C.3070002@imgtec.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 10/27/2015 02:15 PM, Leonid Yegoshin wrote: > On 10/27/2015 02:02 PM, David Daney wrote: >> On 10/27/2015 01:46 PM, Leonid Yegoshin wrote: >> [...] >>> >>> And finally. clock scaling - what we would do if there are two CPUs with >>> different clock ratios in system? It seems like common kernel timing >>> subsystem can handle that. >>> >> >> The code that executes in userspace must have access to a consistent >> clock source. If you are running on a SMP system that doesn't have >> synchronized CP0.Count registers, then your gettimeofday() cannot use >> CP0.Count (RDHWR $2). > > Right, I agree. > >> >> As far as I know, CP0.Count is the only available counter visible to >> userspace, so you would have to disable the accelerated versions of >> gettimeofday() where you cannot assert that the counters are always >> synchronized. > > Any system with GIC may have access to the same GIC global counter in a > special separate page available for mapping by user in RO mode and it > seems Alex did that. > > Besides that this GIC global counter is used as a major system > clocksource in systems with GIC. Yes, I had forgotten about the GIC thing. In any event, there is a set of systems where we could run into problems with unsynchronized clocks. There needs to be an easy way to enable/disable the gettimeofday() acceleration at run time based on the properties of the counter (GIC, CP0.Count, or whatever) chosen at boot time. For example, On OCTEON single-chip systems we synchronize the the counters and they don't drift. So, we can use CPO.Count. However, on two-chip NUMA configurations there may be clock drift between the two chips, so CPO.Count cannot be used as a clocksource. We have a single kernel image that runs on both types of systems, so we have to be able to enable/disable the gettimeofday() acceleration. David Daney > > - Leonid > > > >