Subject: Re: [RFC] Fast assurate clock readable from user space and NMI
	handler
From: Daniel Walker <dwalker@mvista.com>
To: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Cc: mbligh@google.com, linux-kernel@vger.kernel.org, johnstul@us.ibm.com,
       mingo@elte.hu
In-Reply-To: <20070227035456.GA15444@Krystal>
References: <20061126170542.GA30771@Krystal>
	 <1164561427.16871.14.camel@localhost.localdomain>
	 <20061126231833.GA22241@Krystal>
	 <1164585589.16871.52.camel@localhost.localdomain>
	 <20070224161906.GA9497@Krystal> <1172340369.24216.31.camel@imap.mvista.com>
	 <20070226205304.GA30800@Krystal> <1172525261.5517.69.camel@imap.mvista.com>
	 <20070226221423.GA2286@Krystal> <1172531521.5517.138.camel@imap.mvista.com>
	 <20070227035456.GA15444@Krystal>
Content-Type: text/plain
Date: Mon, 26 Feb 2007 20:22:41 -0800
Message-Id: <1172550161.5517.210.camel@imap.mvista.com>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1260
Lines: 28

On Mon, 2007-02-26 at 22:54 -0500, Mathieu Desnoyers wrote:
> If an NMI nests over the spinlock, we have a deadlock.

Maybe not completely safe ...

> In addition, clock->cycle_last is a cycle_t, defined as a 64 bits on
> x86. If is therefore not updated atomically by change_clocksource,
> timekeeping_init, timekeeping_resume and update_wall_time. If an NMI
> fires right on top of the update, especially around the 32 bits wrap
> around, the time will be really fuzzy.

I'm not sure that is particularly significant considering that it's just
a possible bad timestamp, and the probability of that happening seems
rather low .. You could also modify NMI calls so they use a different
time stamping method, like reading the clocksource directly .

The pit clocksource could be dropped pretty easy with my clocksource
update patches, which I'm still working on but you could easily drop
clock sources that aren't atomic like the pit .. Also the pit is
generally undesirable, so it's not going to be missed.

Daniel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/