[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <57C9024A16AD2D4C97DC78E552063EA35CB955B4@orsmsx505.amr.corp.intel.com>
Date: Tue, 6 Jan 2009 12:34:06 -0800
From: "Luck, Tony" <tony.luck@...el.com>
To: Robin Holt <holt@....com>
CC: Dimitri Sivanich <sivanich@....com>,
"linux-ia64@...r.kernel.org" <linux-ia64@...r.kernel.org>,
Greg KH <greg@...ah.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
Gregory Haskins <ghaskins@...ell.com>,
Nick Piggin <npiggin@...e.de>, Tony Luck <tony.luck@...il.com>
Subject: RE: [PATCH] configure HAVE_UNSTABLE_SCHED_CLOCK for SGI_SN systems
> > All ia64 systems are potentially affected ... but perhaps you might
> > never see the problem on most because the itc clocks are synced as close
> > as s/w can get them when cpus are brought on line.
>
> Do you want Dimitri to resubmit with this set for all IA64 or leave it
> as is?
I'd like to understand the impact of turning on HAVE_UNSTABLE_SCHED_CLOCK
It looks like both the i386_defconfig and x86_64_defconfig choose this,
so at least ia64 will be hitting the well tested code paths
Have the other architectures just not hit this yet? Or do they all have
"stable" sched_clock() functions?
sched_clock() seemed like such a straightforward thing to begin with. A
quick & easy way to measure a time delta ON THE SAME CPU. I'm not at
all sure why it has been co-opted for general time measurement.
-Tony
--
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