lkml.org 
[lkml]   [2013]   [Jun]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectUsing sched_clock() for polling time limit
From
Date
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.



\
 
 \ /
  Last update: 2013-06-28 20:01    [W:0.061 / U:1.900 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site