Prev: [patch] padata: add parenthesis in MAX_SEQ_NR macro
Next: sched: Track and export per task [hard|soft]irq time
From: Peter Zijlstra on 25 May 2010 17:40
On Tue, 2010-05-25 at 11:07 -0700, Divyesh Shah wrote:
> Peter, this only affects some stats collection and no scheduling
> behavior should be affected by this. Besides this call at rq_init() to
> sched_clock() there are other calls in the request dispatch and the
> request completion path. Not sure if those are problematic too.
>
> @Ingo, about your concern of time going backwards. This could happen
> with sched_clock() as well when successive measurements were made on
> different cpus which are slightly out of sync. This case is handled
> well in all places where this was used.

You really shouldn't be using sched_clock(), that thing can exhibit
unbounded drift between cpus.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Peter Zijlstra on 12 Jun 2010 05:50
On Fri, 2010-06-11 at 18:54 -0700, Divyesh Shah wrote:
> I was able to repro the issue and and have a patch that
> replaces use of sched_clock() in block layer w/
> ktime_to_ns(ktime_get()).

You know ktime_get() is terrifyingly expensive, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [patch] padata: add parenthesis in MAX_SEQ_NR macro
Next: sched: Track and export per task [hard|soft]irq time