[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1310724097.2586.296.camel@twins>
Date: Fri, 15 Jul 2011 12:01:37 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: john stultz <johnstul@...ibm.com>
Cc: Willy Tarreau <w@....eu>, Ingo Molnar <mingo@...e.hu>,
"MINOURA Makoto / ?$BL'1: ?$B??" <minoura@...inux.co.jp>,
Andrew Morton <akpm@...ux-foundation.org>,
Faidon Liambotis <paravoid@...ian.org>,
linux-kernel@...r.kernel.org, stable@...nel.org,
Nikola Ciprich <nikola.ciprich@...uxbox.cz>,
seto.hidetoshi@...fujitsu.com,
Hervé Commowick <hcommowick@...sec.fr>,
Rand@...per.es
Subject: Re: 2.6.32.21 - uptime related crashes?
On Thu, 2011-07-14 at 17:35 -0700, john stultz wrote:
>
> Peter/Ingo: Can you take a look at the above and let me know if you find
> it too disagreeable?
+static unsigned long long __cycles_2_ns(unsigned long long cyc)
+{
+ unsigned long long ns = 0;
+ struct x86_sched_clock_data *data;
+ int cpu = smp_processor_id();
+
+ rcu_read_lock();
+ data = rcu_dereference(per_cpu(cpu_sched_clock_data, cpu));
+
+ if (unlikely(!data))
+ goto out;
+
+ ns = ((cyc - data->base_cycles) * data->mult) >> CYC2NS_SCALE_FACTOR;
+ ns += data->accumulated_ns;
+out:
+ rcu_read_unlock();
+ return ns;
+}
The way I read that we're still not wrapping properly if freq scaling
'never' happens.
Because then we're wrapping on accumulated_ns + 2^54.
Something like resetting base, and adding ns to accumulated_ns and
returning the latter would make more sense.
--
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