lkml.org 
[lkml]   [2005]   [Jul]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: long delays (possibly infinite) in time_interpolator_get_counter
From
Date
On Fri, 2005-07-29 at 16:31 -0700, Christoph Lameter wrote:
> What you are dealing with is a machine that is using ITC as a time bases.
> That is a special case.

The default time source for ia64 systems is a "special case"? 4
socket and smaller boxes typically do not have any other time source.

> The fix should not affect machines that have a
> proper time source. More below. You can circumvent the compensation for
> ITC inaccuracies by specifying "nojitter" on the kernel command if you are
> willing to take the risk of slightly inaccurate time.

And what if you don't have any HPET and aren't willing to take that
risk? We need a solution that works with all time sources. A system
with the default time source should not hang or have unreasonable delays
with the standard setup. Why is a synchronized ITC driven from a common
clock such a terrible time source for small systems?

> Well get a proper time source and do not use ITC for a time source in an
> SMP system. Got HPET hardware?

No, HPET on small boxes is unnecessary, we should be able to come up
with something that can effectively use the ITC. Does a seqlock really
make sense for the do_gettimeofday() path? This problem arises because
a reader of time is actually updating and writing a part of time. It
would certainly be too much overhead to obtain a write lock for every
gettimeofday(), but to avoid that we have to put some kind of contention
avoidance in the path. I don't know whether that should be some kind of
back-off algorithm at the point of contention w/ the cmpxchg or up
higher with a new seqlock read entry point that blocks when a write is
in progress. In any case, I think we need to focus on a solution that
works well on all systems, not just those with extra timer hardware.
Thanks,

Alex



-
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/

\
 
 \ /
  Last update: 2005-07-30 18:51    [W:0.085 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site