Re: [Xenomai] RT_TASK affinity on more than 8 CPU's

[Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>]

On 07/23/2012 12:02 PM, Philippe Gerum wrote:>> If we want to change
that, we have to fix Xenomai, which supposes there

>> is only one "timer_freq" (rthal_tunables.timer_freq). We can probably
>> get away with setting RTHAL_TIMER_FREQ to a per_cpu variable on all
>> architectures but arm which uses the frequency to pre-compute a
>> multiplicand to avoid division when converting between cpu frequency and
>> timer frequency in xnarch_program_timer_shot.
>>
> 
> Maybe it's time to move the hrtimer-freq <-> hrclock-freq computations 
> to some globally visible helpers into the pipeline core. Then, the 
> arch-dep sections of the pipeline could go wild doing these computations 
> the way they want to, without affecting the interface anymore. 
> Typically, there is nothing which would prevent us from introducing 
> ipipe_timer_program(u64 tsc), assuming that such value must be based on 
> our hrclock.


It means moving the asm/arith.h code to I-pipe, but since we need it to
support older patches, this means a whole new source of code duplication.

If you mean passing an absolute date to program the timer, I had thought
about it, I am not sure this is the right way to go:

- most ipipe timers use the clock_event callback anyway, which use a
delay as argument.
- it has problems of its own, basically, you have to do what all
free-running counter + match register do: re-read the free-running
counter after programming the match register to check that the
programmed date is not alread passed.
- On hardware timers with free-running counter and match register, this
avoids the problem of taking into account the timer calibration, but the
problem remains for decrementers (the most common case, anyway), and it
means that the calibration code would be moved to the I-pipe patch too,
and we have the code duplication issue again.

> 
>> Otherwise, we can pass a cpumask to ipipe_request_timers to tell on what
>> cpus we need timer.
>>
> 
> As I said: this is NOT a structural change. The problem statement is 
> plain trivial, and we can address it, by evolving the I-pipe interface 
> for more flexibility in handling clock devices, which in turn should 
> remove such burden from the Xenomai core. The very initial
> 
> The point we are discussing is about whether using different clock 
> devices to decouple the linux timekeeping machinery from the Xenomai 
> timer subsystem is in essence possible. We seem to agree that this is 
> possible without going back to the drawing board, which is the good news 
> of the day.
> 
>> If we do not fix that one way or another, anyone wanting to use another
>> timer than the default ones will have to provide a timer for each cpu core.
>>
> 
> Incidentally, I'm moving the pipeline core to 3.4, so this may be a good 
> opportunity to update the timer interface we expose to client domains as 
> well.


I would be in favor of adding the cpumask parameter to
ipipe_request_timers: it means that the "all timers with the same
frequency" issue will be restricted to cpus which xenomai wants to use.
And we have an issue when using the "supported_cpus" feature.

As I said, ipipe_request_timers will grab all the timers and switch them
to one-shot mode. However, Xenomai will only take control of some of them.

So, if the timers were running in periodic mode when
ipipe_request_timers was called (so, if CONFIG_HIGH_RES_TIMERS is not
enabled), and xenomai does not take control of them, it means the timer
will not be reprogrammed after the first tick: we just stopped the
periodic timer on the cpus xenomai will not use. Admittedly, this is a
corner case, but still, it exists.

There is a possible fix without breaking the interface, but we still get
the silly common frequency requirement.

I am also working on the core-3.4 branch right now.

-- 
                                                                Gilles.