lkml.org 
[lkml]   [2005]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Need better is_better_time_interpolator() algorithm
On Thu, 25 Aug 2005, Alex Williamson wrote:

> I don't really know if this makes sense, but it seems to do what I
> think it should. If I where to add another node to the system, I would
> more strongly favor the HPETs time, if I removed a node I would revert
> to the cycle counter. Anyway, I think it might be a good starting point
> for further experimentation. Patch below.


Adding a node to the time interpolator does not make much sense since time
needs to be universally accessible in order to be comparable. Unless you
want to use the time interpolator time source as an interrupt source
then you may want to change the node that the timer interrupt runs on.

Some time source like the Altix RTC are not bound to any node but are
available with a node local mmio instruction. There is no way to assign a
node number to it.

Moreover you may derive the node number from the mmio address if the need
really arises.

Also the latency is only a minor criterion in the determination of the
most suitable clock. More important are the clock characteristics like
consistency over multiple processors, or the distribution of the timer.

One does not want a clock that is not consistent over multiple processors
regardless of the latency. A distributed timer wins over a low latency
timer on a node in a NUMA system.

I think it would be best add some flags that describe

1. The consistency scope of the time source
i.e. TIME_SOURCE_SYNC_PROCESSOR
Access to the time source yields a processor local
result
TIME_SOURCE_SYNC_NODE
Access to the time source yields a result that is the same
for all processors on the same node
TIME_SOURCE_SYNC_GLOBAL
Access to the time source yields a globally consistent
result

2. The locality of the time source
TIME_SOURCE_IN_PROCESSOR -> Processor is the time source
TIME_SOURCE_DISTRIBUTED -> Distributed time source
TIME_SOURCE_NODE -> memory mapped time source on a
node.

Then the ITC would be configured as
TIME_SOURCE_SYNC_PROCESSOR | TIME_SOURCE_IN_PROCESSOR

If the ITC is syncd up per node
TIME_SOURCE_SYNC_NODE | TIME_SOURCE_IN_PROCESSOR

If this is an SMP system then it may even be
TIME_SOURCE_SYNC_GLOBAL | TIME_SOURCE_IN_PROCESSOR

For HPET this would be
TIME_SOURCE_SYNC_GLOBAL | TIME_SOURCE_NODE

For Altix RTC
TIME_SOURCE_SYNC_GLOBAL | TIME_SOURCE_DISTRIBUTED

Hope this makes sense.

-
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-08-26 18:58    [W:0.110 / U:0.284 seconds]
©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site