All of lore.kernel.org
 help / color / mirror / Atom feed
From: Shailabh Nagar <nagar@watson.ibm.com>
To: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Cc: Andrew Morton <akpm@osdl.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: [Patch 1/4] Delay accounting: Initialization
Date: Tue, 15 Nov 2005 10:19:17 -0500	[thread overview]
Message-ID: <4379FC75.80704@watson.ibm.com> (raw)
In-Reply-To: <20051115064954.GB31904@logos.cnet>

Marcelo Tosatti wrote:
> On Mon, Nov 14, 2005 at 08:20:17PM -0800, Andrew Morton wrote:
> 
>>Shailabh Nagar <nagar@watson.ibm.com> wrote:
>>
>>>+	*ts = sched_clock();
>>
>>I'm not sure that it's kosher to use sched_clock() for fine-grained
>>timestamping like this.  Ingo had issues with it last time this happened?  
> 
> 
> If the system boots with use_rtc == 0 you're going to get jiffies based
> resolution from sched_clock(). I have a 1GHz Pentium 3 around here which
> does that.

Good point, thanks. This reemphasizes the need for better normalization
at output time.

> Maybe use do_gettimeofday() for such systems?

Perhaps getnstimeofday() so resolution isn't reduced to msec level unnecessarily.
In these patches, userspace takes responsibility for handling wraparound so
delivering a reasonably high-resolution delay data from the kernel is preferable.

> 
> Would be nice to have a sort of per-arch overridable "gettime()" function?
> 

Provided as part of this patch ?


>><too lazy to read all the code> Do you normalise these numbers in some
>>manner before presenting them to userspace?  If so, by what means?




  reply	other threads:[~2005-11-15 15:15 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-11-15  4:35 [Patch 1/4] Delay accounting: Initialization Shailabh Nagar
2005-11-15  4:20 ` Andrew Morton
2005-11-15  6:49   ` Marcelo Tosatti
2005-11-15 15:19     ` Shailabh Nagar [this message]
2005-11-15 12:20       ` Marcelo Tosatti
2005-11-15 12:34         ` Marcelo Tosatti
2005-11-15 15:08   ` Shailabh Nagar
2005-11-16  1:06   ` Peter Chubb
2005-11-16  1:48     ` Shailabh Nagar
2005-11-16  1:50       ` Andi Kleen
2005-11-16  1:52       ` Peter Chubb
2005-11-15  4:25 ` Parag Warudkar
2005-11-15 22:29   ` Shailabh Nagar
2005-11-15 22:53     ` Parag Warudkar
2005-11-16  0:45       ` Shailabh Nagar
2005-11-16  2:41         ` Parag Warudkar

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=4379FC75.80704@watson.ibm.com \
    --to=nagar@watson.ibm.com \
    --cc=akpm@osdl.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcelo.tosatti@cyclades.com \
    --cc=mingo@elte.hu \
    /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.