Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933489Ab0KOUGb (ORCPT ); Mon, 15 Nov 2010 15:06:31 -0500 Received: from relais.videotron.ca ([24.201.245.36]:54138 "EHLO relais.videotron.ca" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756093Ab0KOUGb (ORCPT ); Mon, 15 Nov 2010 15:06:31 -0500 MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; charset=US-ASCII Date: Mon, 15 Nov 2010 15:06:29 -0500 (EST) From: Nicolas Pitre X-X-Sender: nico@xanadu.home To: Peter Zijlstra Cc: Linus Walleij , lkml , Thomas Gleixner , Colin Cross , John Stultz , Ingo Molnar , Rabin Vincent Subject: Re: [PATCH] clocksource: document some basic concepts In-reply-to: <1289818094.2109.487.camel@laptop> Message-id: References: <1289817228-14838-1-git-send-email-linus.walleij@stericsson.com> <1289818094.2109.487.camel@laptop> User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1513 Lines: 37 On Mon, 15 Nov 2010, Peter Zijlstra wrote: > On Mon, 2010-11-15 at 11:33 +0100, Linus Walleij wrote: > > +The sched_clock() function may wrap only on unsigned long long boundaries, > > +i.e. after 64 bits. Since this is a nanosecond value this will mean it wraps > > +after circa 585 years. (For most practical systems this means "never".) This is not necessarily the case. Some implementations require a scaling factor too, making the number of remaining bits smaller than 64. See arch/arm/mach-pxa/time.c:sched_clock() for example, which has a maximum range of 208 days. Of course, in practice we don't really care if sched_clock() wraps each 208 days, unlike for clock-source. > Currently true, John Stultz was going to look into ammending this by > teaching the kernel/sched_clock.c bits about early wraps (and a way for > architectures to specify this) > > #define SCHED_CLOCK_WRAP_BITS 48 > > ... > > #ifdef SCHED_CLOCK_WRAP_BITS > /* handle short wraps */ > #endif Is this worth supporting? I'd simply use the low 32 bits and extend it to 63 bits using cnt32_to_63(). If the low 32 bits are wrapping too fast, then just shifting them down a few positions first should do the trick. That certainly would have a much faster result. Nicolas -- 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/