public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox