Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S266560AbUIOPxl (ORCPT ); Wed, 15 Sep 2004 11:53:41 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S266534AbUIOPxN (ORCPT ); Wed, 15 Sep 2004 11:53:13 -0400 Received: from omx1-ext.sgi.com ([192.48.179.11]:23490 "EHLO omx1.americas.sgi.com") by vger.kernel.org with ESMTP id S266543AbUIOPu3 (ORCPT ); Wed, 15 Sep 2004 11:50:29 -0400 Date: Wed, 15 Sep 2004 08:46:53 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: George Anzinger cc: john stultz , Albert Cahalan , lkml , tim@physik3.uni-rostock.de, Ulrich.Windl@rz.uni-regensburg.de, Len Brown , linux@dominikbrodowski.de, David Mosberger , Andi Kleen , paulus@samba.org, schwidefsky@de.ibm.com, jimix@us.ibm.com, keith maanthey , greg kh , Patricia Gaughen , Chris McDermott Subject: Re: [RFC][PATCH] new timeofday core subsystem (v.A0) In-Reply-To: <4147F774.6000800@mvista.com> Message-ID: References: <1094159238.14662.318.camel@cog.beaverton.ibm.com> <4137CB3E.4060205@mvista.com> <1094193731.434.7232.camel@cube> <41381C2D.7080207@mvista.com> <1094239673.14662.510.camel@cog.beaverton.ibm.com> <4138EBE5.2080205@mvista.com> <1094254342.29408.64.camel@cog.beaverton.ibm.com> <41390622.2010602@mvista.com> <1094666844.29408.67.camel@cog.beaverton.ibm.com> <413F9F17.5010904@mvista.com> <1094691118.29408.102.camel@cog.beaverton.ibm.com> <1094700768.29408.124.camel@cog.beaverton.ibm.com> <413FDC9F.1030409@mvista.com> <1094756870.29408.157.camel@cog.beaverton.ibm.com> <4140C1ED.4040505@mvista.com> <1095114307.29408.285.camel@cog.beaverton.ibm.com> <41479369.6020506@mvista.com> <4147F774.6000800@mvista.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1651 Lines: 37 On Wed, 15 Sep 2004, George Anzinger wrote: > Lets assume the pm counter which has 24 bits. This means your shift is 40 bits. > In "s->multiply = (NSEC_PER_SEC << s->shift) / freq;" you will have an overflow. > Here you need to keep (NSEC_PER_SEC << s->shift) in 64 bits AND multiply must > also be 32 bits or less. I really don't think you can choose the scale so easily. Thanks for pointing that out. Will fix that. I sure wish one could have a 128 bit intermediate result. > > Nope. time_source_last is the global. l is just a copy of > > time_source_last. > > Right, I miss read the function. cycles() should be now() if I am reading this > right. Sortof. now() is the time in nanoseconds whereas cycles() is a counter value of the counter in the cpu. > > One could do this but we want to have a tickless system. The tick is only > > necessary if the time needs to be adjusted. > > I really think a tickless system, for other than UML systems, is a loosing > thing. The accounting overhead on context switch (which increases as the number > of switchs per second) will cause more overhead than a periodic accounting tick > once a respectable load appears. The periodic accounting tick has a flat > overhead that does not depend on load. I am not following you here. Why does the context switch overhead increase? Because there are multiple interrupts for different tasks done in the tick? - 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/