Re: [Xenomai-core] official TSC model on SMP

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]

Gilles Chanteperdrix wrote:
> Philippe Gerum wrote:
>  > On Sun, 2006-09-17 at 13:54 +0200, Jan Kiszka wrote:
>  > > Hi,
>  > > 
>  > > reading through timer code of Xenomai I just wondered (again) what our
>  > > official model of TSCs on multiprocessor boxes are:
>  > > 
>  > > 1) (practically) perfectly synchronised without offset
>  > > 
>  > > 2) synchronised but with (unknown?) offset
>  > > 
>  > > 3) unsynchronised
>  > 
>  > The current model is unsynchronized. If anything from the codebase is
>  > found relying on the opposite, be it partially or fully, then it's
>  > utterly broken in the SMP case, and I'm likely the one to blame.
>  > IOW, we don't currently provide any guarantee to anyone that a timestamp
>  > could be interpreted anywhere else than the CPU it was read from, and
>  > leave all the related burden to the application developer (e.g. by mean
>  > of managing CPU affinity constraints and the like).
> 
> I think xntimer_set_sched assumes some continuity, since it reenqueues
> on a different CPU a timer whose date has been set up on one cpu. If we
> wanted strict unsynchronized tsc, we would have to :
> - compute the difference between the current date and the timer date
> - enqueue the timer on a migration queue
> - send an IPI to the distant CPU
> - on the distant CPU, iterate over the migration queue, recompute the
>   expiration dates and reenqueue the timers.
> 

I bet there are a few other wrong assumptions about dates hogging around
in our design. At least all timestamp deliveries of RTDM devices on SMP
fall into this group.

It's a fairly unsatisfying situation. How common are unsynchronised
TSCs, also on non x86 archs? I though so far that's an issue of a few
newer AMD multicore CPUs only. I once read the Solaris x86 timer code,
and they, e.g., demand synch'ed TSC IIRC.

Can we make the unsynch'ed case somehow the exception and deal with it
separately (via periodic re-synch based on IPI)? Would make life easier,
though I agree that explicit CPU scheduling of tasks and IRQs are more
appropriate to RT systems. But sometimes you cannot put the IRQ on the
same CPU like the woken up task...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]