[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1274942798.27810.3584.camel@twins>
Date: Thu, 27 May 2010 08:46:38 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: piotr@...owicz.com, linux-kernel@...r.kernel.org,
Jens Axboe <jens.axboe@...cle.com>,
Divyesh Shah <dpshah@...gle.com>
Subject: Re: BUG: using smp_processor_id() in preemptible [00000000] code:
icedove-bin/5449
On Wed, 2010-05-26 at 16:02 -0700, Andrew Morton wrote:
> How is anyone supposed to use this? What are the semantics of this
> thing? What are the units of its return value? What is the base value
> of its return value? Does it return different times on different CPUs?
> I assume so, otherwise why does sched_clock_cpu() exist? <looks at
> the sched_clock_cpu() documentation, collapses in giggles>
The point of the whole sched_clock_cpu() thing is to provide a fairly
high resolution clock with bounded drift between cpus.
It also promises to be monotonic per cpu argument, that is,
sched_clock_cpu(j) will, for a constant j always return a monotonic
increasing timestamp.
It doesn't make much promises about its base (although people tend to
want it to start at 0 on boot, but the users really shouldn't care).
sched_clock() doesn't promise either bounded drift between cpus nor
monotonicity.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists