From: Helge Deller <deller@gmx.de>
To: john stultz <johnstul@us.ibm.com>
Subject: Re: [RFC][PATCH] use cycle_t instead of u64 in struct time_interpolator
Date: Wed, 3 Jan 2007 21:23:21 +0100
User-Agent: KMail/1.9.5
Cc: Christoph Lameter <clameter@sgi.com>, linux-kernel@vger.kernel.org,
       parisc-linux@lists.parisc-linux.org
References: <200701022233.25697.deller@gmx.de> <200701031936.36423.deller@gmx.de> <1167851879.5937.8.camel@localhost.localdomain>
In-Reply-To: <1167851879.5937.8.camel@localhost.localdomain>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="utf-8"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200701032123.21276.deller@gmx.de>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2591
Lines: 51

On Wed Jan 3 2007, john stultz wrote:
> On Wed, 2007-01-03 at 19:36 +0100, Helge Deller wrote:
> > On Wed Jan 3 2007, Christoph Lameter wrote:
> > > On Tue, 2 Jan 2007, Helge Deller wrote:
> > >
> > > > As far as I could see, this patch does not change anything for the
> > > > existing architectures which use this framework (IA64 and SPARC64),
> > > > since "cycles_t" is defined there as unsigned 64bit-integer anyway
> > > > (which then makes this patch a no-change for them).
> > >
> > > The 64bit nature of some entities was so far necessary to get the
> > > proper accuracy of interpolation. Maybe it can be made to work with 32 bit
> > > entities. The macro GET_TI_SECS must work correctly and the less bits are
> > > specified in shift the less self-tuning accuracy you will get.
> > 
> > Yes, it was easily possible to make it 32bit-ready without loosing the accuracy.
> > 
> > Nevertheless, in the meantime John Stultz pointed me to the CONFIG_GENERIC_TIME framework,  and I implemented it that way:
> > http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=b6de83b58b8b07f057deacdef8a95b6c32d1c4e6
> 
> This looks pretty good, although setting the rating to 200 for a
> clocksource you don't want to use seems a bit high (there's a rough
> rating scale in clocksource.h). Zero is probably what you want to use
> there.
> 
> > http://git.parisc-linux.org/?p=linux-2.6.git;a=commit;h=f70a979c843e4610edfb2a316648fe8ae8718f69
> 
> This looks to be correct, although as the clocksource infrastructure
> evolves it looks like we'll be removing the update_callback code in the
> future. So this is fine for now, but will probably need a reevaluation
> at some point.
> 
> Also to avoid jumping between clocksources, I'd keep the initial
> disqualification that occurs before you register the clocksource
> (otherwise it will be used for one tick, then be disqualified and you're
> back to jiffies).

That's true, but James Bottomley noticed, that time_init() is called before 
we've done system inventory (which detects if we have a SMP box with multiple CPUs),
so num_online_cpus() would always be one. The update_callback function enables
us to switch back to jiffies if we actually run on a SMP box.

That said, it would be nice to keep the update_callback() functionality or provide another
nice solution around that problem...

Helge
-
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/