All of lore.kernel.org
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: john stultz <johnstul@us.ibm.com>
Cc: lkml <linux-kernel@vger.kernel.org>,
	Tim Schmielau <tim@physik3.uni-rostock.de>,
	George Anzinger <george@mvista.com>,
	albert@users.sourceforge.net,
	Ulrich Windl <ulrich.windl@rz.uni-regensburg.de>,
	Christoph Lameter <clameter@sgi.com>,
	Dominik Brodowski <linux@dominikbrodowski.de>,
	David Mosberger <davidm@hpl.hp.com>, Andi Kleen <ak@suse.de>,
	Paul Mackerras <paulus@samba.org>,
	schwidefsky@de.ibm.com, keith maanthey <kmannth@us.ibm.com>,
	Patricia Gaughen <gone@us.ibm.com>,
	Chris McDermott <lcm@us.ibm.com>, Max Asbock <amax@us.ibm.com>,
	mahuja@us.ibm.com, Nishanth Aravamudan <nacc@us.ibm.com>,
	Darren Hart <darren@dvhart.com>,
	"Darrick J. Wong" <djwong@us.ibm.com>,
	Anton Blanchard <anton@samba.org>
Subject: Re: [RFC][PATCH] new timeofday arch specific hooks (v. A2)
Date: Wed, 26 Jan 2005 10:53:47 +1100	[thread overview]
Message-ID: <1106697227.5235.28.camel@gaston> (raw)
In-Reply-To: <1106694561.30884.52.camel@cog.beaverton.ibm.com>

On Tue, 2005-01-25 at 15:09 -0800, john stultz wrote:

> The performance is a concern, and right now there are issues (ntp_scale
> being the top of the list) however I hope they can be resolved. Looking
> at ppc64's do_gettimeofday() vs this implementation there we do have
> more overhead, but maybe you could suggest how we can avoid some of it?

I would suggest reclaculating the scale factor and offset for ntp
adjustement regulary from the timer tick or so, not on each gettimeofday
call.

Also, I have some updates to the ppc64 implementation where I regulary
update the pre-scale offset into the post-scale one so that the
timebase-prescale substraction always gives a 32 bits number. I do that
so my fast userland gettimeofday can be implemented more easily and more
efficiently for 32 bits processes. I yet have to check how I can hook
those things into your new scheme.

> I still want to support vsyscall gettimeofday, although it does have to
> be done on an arch-by-arch basis. It's likely the systemcfg data
> structure can still be generated and exported. I'll look into it and see
> what can be done.

Well, since it only contains the prescale and postscale offsets and the
scaling value, it only needs to be updated when they change, so a hook
here would be fine.

Ben.



  reply	other threads:[~2005-01-26  0:03 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-24 22:51 [RFC][PATCH] new timeofday core subsystem (v. A2) john stultz
2005-01-24 22:52 ` [RFC][PATCH] new timeofday arch specific hooks " john stultz
2005-01-24 22:53   ` [RFC][PATCH] new timeofday arch specific timesources " john stultz
2005-01-24 23:29     ` Christoph Lameter
2005-01-25  0:04       ` john stultz
2005-01-25  2:28   ` [RFC][PATCH] new timeofday arch specific hooks " Benjamin Herrenschmidt
2005-01-25 23:09     ` john stultz
2005-01-25 23:53       ` Benjamin Herrenschmidt [this message]
2005-01-26  0:17         ` john stultz
2005-01-26  0:34           ` Christoph Lameter
2005-01-26  3:29             ` Benjamin Herrenschmidt
2005-01-26 16:51               ` Christoph Lameter
2005-01-26  3:14           ` Benjamin Herrenschmidt
2005-01-24 23:24 ` [RFC][PATCH] new timeofday core subsystem " Christoph Lameter
2005-01-25  0:03   ` john stultz
2005-01-25  0:08     ` Christoph Lameter
2005-01-25  0:33       ` john stultz
2005-01-25  1:54         ` Christoph Lameter
2005-01-25  7:50           ` Ulrich Windl
2005-01-25 12:25           ` Tim Schmielau
2005-01-25  7:41   ` Ulrich Windl
2005-01-25  8:17 ` Andi Kleen
2005-01-25 23:18   ` john stultz
2005-02-01 22:06 ` Tim Bird
2005-02-01 22:48   ` john stultz
2005-02-01 23:14     ` Nigel Cunningham
2005-02-01 23:32       ` john stultz
2005-02-02  0:04         ` Nigel Cunningham
2005-02-02  0:27           ` john stultz
2005-02-02  0:36             ` Nigel Cunningham
2005-02-01 23:53     ` Tim Bird
2005-02-02  0:19       ` john stultz
2005-02-02  1:48         ` Tim Bird
2005-02-02  2:00           ` john stultz
2005-02-02  2:23             ` Nigel Cunningham
     [not found] <OFF640EFCB.17A81893-ON41256F95.0033EA1D-41256F95.00342F11@de.ibm.com>
2005-01-26 16:52 ` [RFC][PATCH] new timeofday arch specific hooks " Christoph Lameter
2005-01-26 17:51   ` David Mosberger

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=1106697227.5235.28.camel@gaston \
    --to=benh@kernel.crashing.org \
    --cc=ak@suse.de \
    --cc=albert@users.sourceforge.net \
    --cc=amax@us.ibm.com \
    --cc=anton@samba.org \
    --cc=clameter@sgi.com \
    --cc=darren@dvhart.com \
    --cc=davidm@hpl.hp.com \
    --cc=djwong@us.ibm.com \
    --cc=george@mvista.com \
    --cc=gone@us.ibm.com \
    --cc=johnstul@us.ibm.com \
    --cc=kmannth@us.ibm.com \
    --cc=lcm@us.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.de \
    --cc=mahuja@us.ibm.com \
    --cc=nacc@us.ibm.com \
    --cc=paulus@samba.org \
    --cc=schwidefsky@de.ibm.com \
    --cc=tim@physik3.uni-rostock.de \
    --cc=ulrich.windl@rz.uni-regensburg.de \
    /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.