From: Jeff Muizelaar <jeff@infidigm.net>
To: Daniel Walker <dwalker@mvista.com>
Cc: "Frank Ch. Eigler" <fche@redhat.com>, linux-kernel@vger.kernel.org
Subject: Re: Using sched_clock for mmio-trace
Date: Fri, 16 Feb 2007 14:34:28 -0500 [thread overview]
Message-ID: <20070216193428.GE6425@infidigm.net> (raw)
In-Reply-To: <1171650530.3422.25.camel@imap.mvista.com>
On Fri, Feb 16, 2007 at 10:28:50AM -0800, Daniel Walker wrote:
> On Fri, 2007-02-16 at 13:10 -0500, Jeff Muizelaar wrote:
> > On Fri, Feb 16, 2007 at 09:45:21AM -0800, Daniel Walker wrote:
> > > I've been working on a patch set (below), to expose the clocksources
> > > used by generic time to multiple users . It would allow timestamps from
> > > different clocks in a generic way. It's not merged, but I'd appreciate
> > > any input either of you might have..
> > >
> > > ftp://source.mvista.com/pub/dwalker/clocksource/
> >
> > Is it possible to see the resulting clocksource.h and maybe
> > clocksource.c after the patch set? That would make looking at it much
> > easier.
>
> Well you could just apply the patch set, but I stuck them in the same
> directory as above .. I'll delete them in 24 hours or so ..
>
> At one point I replaced sched_clock() ,
>
> ftp://source.mvista.com/pub/dwalker/clocksource/clocksource-v10/add_generic_sched_clock.patch
>
> The API is similar to that version, and sched_clock was the simplest
> user of the API that I've done.
Ok, so it would basically be:
init()
{
clocksource *clock = clocksource_get_best_clock();
}
trace()
{
trace.time = cyc2ns(clock, clocksource_read(clock));
}
This seems pretty sane to me.
The blk-trace code calibrates a per cpu offset for the sched_clock()
time (see blk_trace_check_cpu_time and blk_trace_set_ht_offsets). Does
the clocksource stuff help me with this or would I still need to do
something like that?
I also noticed that you have a clocksource_get_masked_clock() call. This
seems like a pretty awkward API to me. The first thing that came to mind
when I read the name was 'what is a masked clock'. When I realized that
it meant 'a clock w/o this flag', I still found it awkward that one has
to specify what that don't want. e.g 'I don't want a clock that is not
continuous.'
It think it would be better if you had sometime like
'clocksource_get_clock_with_features()' that took flags describing the
needed characteristics instead of the unwanted ones.
e.g.
clocksource_get_clock_with_features(CLOCKSOURCE_STABLE)
or
clocksource_get_clock_with_features(CLOCKSOURCE_PM_UNAFFECTED)
instead of:
clocksource_get_clock_masked(CLOCKSOURCE_UNSTABLE)
clocksource_get_clock_masked(CLOCKSOURCE_PM_AFFECTED)
Especially awkward is the CLOCKSOURCE_64BIT flag, as there isn't really
anyway to specify that I want a 64bit timer, only a way to specify that
I don't.
It also isn't clear what the implications of some of the flags are:
e.g:
NOT_CONTINUOUS - don't really have any idea what this means.
UNSTABLE - this means the frequency can change right?
Does PM_AFFECTED imply UNSTABLE?
NOT_ATOMIC - does this affect me as user?
PM_AFFECTED - it looks like the stp code deals with cpu speed
changing. Does the clocksource code do this for me with
cyc2ns? If it does are there any reason I would want to
avoid PM_AFFECTED clocks? If it doesn't how do I know
that I need to correct it myself.
Hope this helps,
-Jeff
next prev parent reply other threads:[~2007-02-16 19:33 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-16 1:30 Using sched_clock for mmio-trace Jeff Muizelaar
2007-02-16 16:30 ` Frank Ch. Eigler
2007-02-16 17:45 ` Daniel Walker
2007-02-16 18:10 ` Jeff Muizelaar
2007-02-16 18:28 ` Daniel Walker
2007-02-16 19:34 ` Jeff Muizelaar [this message]
2007-02-16 21:06 ` Daniel Walker
2007-02-16 22:10 ` Jeff Muizelaar
2007-02-16 22:47 ` Daniel Walker
2007-02-17 4:36 ` Jeff Muizelaar
2007-02-16 18:30 ` Jeff Muizelaar
2007-02-16 18:44 ` Randy Dunlap
2007-02-16 19:55 ` Jeff Muizelaar
2007-02-16 20:03 ` Andi Kleen
2007-02-16 21:26 ` Frank Ch. Eigler
2007-02-17 14:56 ` Andi Kleen
2007-02-17 15:19 ` Thomas Gleixner
2007-02-18 17:20 ` Andi Kleen
2007-02-16 20:02 ` Andi Kleen
2007-02-16 19:40 ` Jeff Muizelaar
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=20070216193428.GE6425@infidigm.net \
--to=jeff@infidigm.net \
--cc=dwalker@mvista.com \
--cc=fche@redhat.com \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox