All of lore.kernel.org
 help / color / mirror / Atom feed
From: Helge Deller <deller@gmx.de>
To: john stultz <johnstul@us.ibm.com>
Cc: Christoph Lameter <clameter@sgi.com>,
	linux-kernel@vger.kernel.org,
	parisc-linux@lists.parisc-linux.org
Subject: Re: [RFC][PATCH] use cycle_t instead of u64 in struct time_interpolator
Date: Wed, 3 Jan 2007 21:23:21 +0100	[thread overview]
Message-ID: <200701032123.21276.deller@gmx.de> (raw)
In-Reply-To: <1167851879.5937.8.camel@localhost.localdomain>

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

  reply	other threads:[~2007-01-03 20:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-02 21:33 [RFC][PATCH] use cycle_t instead of u64 in struct time_interpolator Helge Deller
2007-01-02 21:44 ` [parisc-linux] " Matthew Wilcox
2007-01-02 21:44 ` Matthew Wilcox
2007-01-03  0:02 ` [parisc-linux] [RFC][PATCH] use cycle_t instead of u64 in struct John David Anglin
2007-01-03  0:02 ` John David Anglin
2007-01-03 17:46 ` [RFC][PATCH] use cycle_t instead of u64 in struct time_interpolator Christoph Lameter
2007-01-03 18:36   ` [parisc-linux] " Helge Deller
2007-01-03 18:36   ` Helge Deller
2007-01-03 19:17     ` john stultz
2007-01-03 20:23       ` Helge Deller [this message]
2007-01-03 20:42         ` john stultz
2007-01-03 20:42         ` john stultz
2007-01-03 20:23       ` [parisc-linux] " Helge Deller
2007-01-03 19:17     ` john stultz
2007-01-03 17:46 ` Christoph Lameter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200701032123.21276.deller@gmx.de \
    --to=deller@gmx.de \
    --cc=clameter@sgi.com \
    --cc=johnstul@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parisc-linux@lists.parisc-linux.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.