[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1372438309.1937.9.camel@bwh-desktop.uk.level5networks.com>
Date: Fri, 28 Jun 2013 17:51:49 +0100
From: Ben Hutchings <bhutchings@...arflare.com>
To: Eliezer Tamir <eliezer.tamir@...ux.intel.com>
CC: David Miller <davem@...emloft.net>, <linux-kernel@...r.kernel.org>,
<netdev@...r.kernel.org>, Willem de Bruijn <willemb@...gle.com>,
Eric Dumazet <erdnetdev@...il.com>,
Andi Kleen <andi@...stfloor.org>, HPA <hpa@...or.com>,
Cody P Schafer <devel-lists@...yps.com>,
Eliezer Tamir <eliezer@...ir.org.il>
Subject: Using sched_clock() for polling time limit
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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists