On Fri, 2013-06-28 at 15:59 +0300, Eliezer Tamir wrote:
> Our use of sched_clock is OK because we don't mind the side effects
> of calling it and occasionally waking up on a different CPU.
Sure about that? Jitter matters too.
> When CONFIG_DEBUG_PREEMPT is on, disable preempt before calling
> sched_clock() so we don't trigger a debug_smp_processor_id() warning.
[...]
I think this is papering over a problem. The warning is there for a
good reason.
Would functions like these make it possible to use sched_clock() safely
for polling? (I didn't spend much time thinking about the names.)
struct sched_timestamp {
int cpu;
unsigned long long clock;
};
static inline struct sched_timestamp sched_get_timestamp(void)
{
struct sched_timestamp ret;
preempt_disable_notrace();
ret.cpu = smp_processor_id();
ret.clock = sched_clock();
preempt_enable_no_resched_notrace();
return ret;
}
static inline bool sched_timeout_or_moved(struct sched_timestamp start,
unsigned long long timeout)
{
bool ret;
preempt_disable_notrace();
ret = start.cpu != smp_processor_id() ||
(sched_clock() - start.clock) > timeout;
preempt_enable_no_resched_notrace();
return ret;
}
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
