> They could be huge differences - unbounded, in fact. It would make
> printk fairly hard to interpret, I would think. The only benefit to
> using sched_clock in printk is that if you're using it to work out the
> startup latencies you won't be confused by stolen time. But I think
> that's a
Andi Kleen wrote:
> Even on real hardware it's also per CPU, although the errors
> are usually not big. At least the scheduler deals with that by
> only ever comparing time stamps from the same CPU.
>
Well, it uses sched_clock to measure how long something has been asleep,
which is inherently
Andrew Morton wrote:
> blktrace. I've seen a couple of trace/debug-style things which use
> sched_clock for timestamping event collection. I think lttng does exotic
> things with TSCs, performing private skew correction, although that might
> have changed now.
>
I'm not worried about things
Andi Kleen wrote:
> They should always just store the cpu too and educate the users that
> only (cpu, timestamp) pairs make sense to compare.
>
> That said at least my new sched_clock should not normally show
> large non differences between CPUs, so it can be usually ignored, but they
> can
>
On Thursday 12 April 2007 19:55:59 Andrew Morton wrote:
> On Thu, 12 Apr 2007 10:43:03 -0700
> Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
> > Andrew Morton wrote:
> > > hm. People (ab)use sched_clock() for all sorts of things nowadays. I
> > > wouldn't
> > > do anything to degrade it
On Thu, 12 Apr 2007 10:43:03 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > hm. People (ab)use sched_clock() for all sorts of things nowadays. I
> > wouldn't
> > do anything to degrade it just on behalf of printk-timestamping.
> >
>
> printk was the only
On Thu, 2007-04-12 at 10:43 -0700, Jeremy Fitzhardinge wrote:
> Andrew Morton wrote:
> > hm. People (ab)use sched_clock() for all sorts of things nowadays. I
> > wouldn't
> > do anything to degrade it just on behalf of printk-timestamping.
> >
>
> printk was the only non-scheduler-ish use I
On Thursday 12 April 2007 19:43:03 Jeremy Fitzhardinge wrote:
> Andrew Morton wrote:
> > hm. People (ab)use sched_clock() for all sorts of things nowadays. I
> > wouldn't
> > do anything to degrade it just on behalf of printk-timestamping.
> >
>
> printk was the only non-scheduler-ish use I
On Thursday 12 April 2007 19:41:51 Jeremy Fitzhardinge wrote:
> Andi Kleen wrote:
> > Ok. I think it's better to just fix sched_clock() again than to
> > add another one. I can probably
> > eliminate the ktime_get() and use something based on jiffies. That will
> > be inaccurate for the instable
Andrew Morton wrote:
> hm. People (ab)use sched_clock() for all sorts of things nowadays. I
> wouldn't
> do anything to degrade it just on behalf of printk-timestamping.
>
printk was the only non-scheduler-ish use I could find. Are there others?
J
-
To unsubscribe from this list: send
Andi Kleen wrote:
> Ok. I think it's better to just fix sched_clock() again than to
> add another one. I can probably
> eliminate the ktime_get() and use something based on jiffies. That will
> be inaccurate for the instable case of course.
>
> I will do that later today.
sched_clock seems a bit
> OK, so I resurrected x86_64-mm-sched-clock-share.patch and
> x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using
> netconsole and printk timestamps too. Removing "time" from the kernel boot
> command line prevents that.
It's not worse than before for you CPU. The old code
On Thu, 12 Apr 2007 18:45:39 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > I was proposing that i386 and x86_64 be given a new, lockless,
> > high-resolution printk_clock(). Presently x86 uses the default
> > printk_clock(), which uses sched_clock(). Presumably copying the
> >
> I was proposing that i386 and x86_64 be given a new, lockless,
> high-resolution printk_clock(). Presently x86 uses the default
> printk_clock(), which uses sched_clock(). Presumably copying the
> pre-x86_64-mm-sched-clock-share.patch version of sched_clock() into
> printk_clock() will
On Thu, 12 Apr 2007 11:36:02 +0200 Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > OK, so I resurrected x86_64-mm-sched-clock-share.patch and
> > x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using
> > netconsole and printk timestamps too. Removing "time" from the kernel boot
>
> OK, so I resurrected x86_64-mm-sched-clock-share.patch and
> x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using
> netconsole and printk timestamps too. Removing "time" from the kernel boot
> command line prevents that.
Ah. But ktime_get shouldn't printk. Or did you change
OK, so I resurrected x86_64-mm-sched-clock-share.patch and
x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using
netconsole and printk timestamps too. Removing time from the kernel boot
command line prevents that.
Ah. But ktime_get shouldn't printk. Or did you change that?
On Thu, 12 Apr 2007 11:36:02 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
OK, so I resurrected x86_64-mm-sched-clock-share.patch and
x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using
netconsole and printk timestamps too. Removing time from the kernel boot
command
I was proposing that i386 and x86_64 be given a new, lockless,
high-resolution printk_clock(). Presently x86 uses the default
printk_clock(), which uses sched_clock(). Presumably copying the
pre-x86_64-mm-sched-clock-share.patch version of sched_clock() into
printk_clock() will suffice.
On Thu, 12 Apr 2007 18:45:39 +0200 Andi Kleen [EMAIL PROTECTED] wrote:
I was proposing that i386 and x86_64 be given a new, lockless,
high-resolution printk_clock(). Presently x86 uses the default
printk_clock(), which uses sched_clock(). Presumably copying the
OK, so I resurrected x86_64-mm-sched-clock-share.patch and
x86_64-mm-sched-clock64.patch. The x86_64 box hangs on boot when using
netconsole and printk timestamps too. Removing time from the kernel boot
command line prevents that.
It's not worse than before for you CPU. The old code did
Andi Kleen wrote:
Ok. I think it's better to just fix sched_clock() again than to
add another one. I can probably
eliminate the ktime_get() and use something based on jiffies. That will
be inaccurate for the instable case of course.
I will do that later today.
sched_clock seems a bit weird
Andrew Morton wrote:
hm. People (ab)use sched_clock() for all sorts of things nowadays. I
wouldn't
do anything to degrade it just on behalf of printk-timestamping.
printk was the only non-scheduler-ish use I could find. Are there others?
J
-
To unsubscribe from this list: send the
On Thursday 12 April 2007 19:41:51 Jeremy Fitzhardinge wrote:
Andi Kleen wrote:
Ok. I think it's better to just fix sched_clock() again than to
add another one. I can probably
eliminate the ktime_get() and use something based on jiffies. That will
be inaccurate for the instable case of
On Thursday 12 April 2007 19:43:03 Jeremy Fitzhardinge wrote:
Andrew Morton wrote:
hm. People (ab)use sched_clock() for all sorts of things nowadays. I
wouldn't
do anything to degrade it just on behalf of printk-timestamping.
printk was the only non-scheduler-ish use I could
On Thu, 2007-04-12 at 10:43 -0700, Jeremy Fitzhardinge wrote:
Andrew Morton wrote:
hm. People (ab)use sched_clock() for all sorts of things nowadays. I
wouldn't
do anything to degrade it just on behalf of printk-timestamping.
printk was the only non-scheduler-ish use I could
On Thu, 12 Apr 2007 10:43:03 -0700
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
hm. People (ab)use sched_clock() for all sorts of things nowadays. I
wouldn't
do anything to degrade it just on behalf of printk-timestamping.
printk was the only
On Thursday 12 April 2007 19:55:59 Andrew Morton wrote:
On Thu, 12 Apr 2007 10:43:03 -0700
Jeremy Fitzhardinge [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
hm. People (ab)use sched_clock() for all sorts of things nowadays. I
wouldn't
do anything to degrade it just on behalf of
Andi Kleen wrote:
They should always just store the cpu too and educate the users that
only (cpu, timestamp) pairs make sense to compare.
That said at least my new sched_clock should not normally show
large non differences between CPUs, so it can be usually ignored, but they
can
happen.
Andrew Morton wrote:
blktrace. I've seen a couple of trace/debug-style things which use
sched_clock for timestamping event collection. I think lttng does exotic
things with TSCs, performing private skew correction, although that might
have changed now.
I'm not worried about things using
Andi Kleen wrote:
Even on real hardware it's also per CPU, although the errors
are usually not big. At least the scheduler deals with that by
only ever comparing time stamps from the same CPU.
Well, it uses sched_clock to measure how long something has been asleep,
which is inherently
They could be huge differences - unbounded, in fact. It would make
printk fairly hard to interpret, I would think. The only benefit to
using sched_clock in printk is that if you're using it to work out the
startup latencies you won't be confused by stolen time. But I think
that's a
On Wed, 11 Apr 2007 14:33:57 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > Here is the call ordering ,
> >
> > ktime_get()
> > ktime_get_ts() -> read_seqretry(_lock, seq)
> > getnstimeofday()
> >__get_realtime_clock_ts() -> read_seqretry(_lock, seq)
> >
> >
> > I wonder if there is
On Wed, 11 Apr 2007 13:54:41 -0700
Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-04-11 at 13:31 -0700, Andrew Morton wrote:
> > On Wed, 11 Apr 2007 09:29:04 -0700
> > Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > The locking of the xtime_lock around the cpu notifier is unessesary
On Wed, 2007-04-11 at 13:31 -0700, Andrew Morton wrote:
> On Wed, 11 Apr 2007 09:29:04 -0700
> Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > The locking of the xtime_lock around the cpu notifier is unessesary now. At
> > one
> > time the tsc was used after a frequency change for timekeeping,
On Wed, 11 Apr 2007 09:29:04 -0700
Daniel Walker <[EMAIL PROTECTED]> wrote:
> The locking of the xtime_lock around the cpu notifier is unessesary now. At
> one
> time the tsc was used after a frequency change for timekeeping, but the
> re-write
> of timekeeping no longer uses the TSC unless the
The locking of the xtime_lock around the cpu notifier is unessesary now. At one
time the tsc was used after a frequency change for timekeeping, but the re-write
of timekeeping no longer uses the TSC unless the frequency is constant.
The variables that are changed in this section of code had also
The locking of the xtime_lock around the cpu notifier is unessesary now. At one
time the tsc was used after a frequency change for timekeeping, but the re-write
of timekeeping no longer uses the TSC unless the frequency is constant.
The variables that are changed in this section of code had also
On Wed, 11 Apr 2007 09:29:04 -0700
Daniel Walker [EMAIL PROTECTED] wrote:
The locking of the xtime_lock around the cpu notifier is unessesary now. At
one
time the tsc was used after a frequency change for timekeeping, but the
re-write
of timekeeping no longer uses the TSC unless the
On Wed, 2007-04-11 at 13:31 -0700, Andrew Morton wrote:
On Wed, 11 Apr 2007 09:29:04 -0700
Daniel Walker [EMAIL PROTECTED] wrote:
The locking of the xtime_lock around the cpu notifier is unessesary now. At
one
time the tsc was used after a frequency change for timekeeping, but the
On Wed, 11 Apr 2007 13:54:41 -0700
Daniel Walker [EMAIL PROTECTED] wrote:
On Wed, 2007-04-11 at 13:31 -0700, Andrew Morton wrote:
On Wed, 11 Apr 2007 09:29:04 -0700
Daniel Walker [EMAIL PROTECTED] wrote:
The locking of the xtime_lock around the cpu notifier is unessesary now.
At
On Wed, 11 Apr 2007 14:33:57 -0700
Andrew Morton [EMAIL PROTECTED] wrote:
Here is the call ordering ,
ktime_get()
ktime_get_ts() - read_seqretry(xtime_lock, seq)
getnstimeofday()
__get_realtime_clock_ts() - read_seqretry(xtime_lock, seq)
I wonder if there is a weird
42 matches
Mail list logo
