Wolfgang Mauerer wrote:
>>>>>> The kernel need to synchronize with user land, so the problem is
>>>>>> (almost) the same as with obtaining the original data from Linux
>>>>>> directly: user land can only use a retry or a smart fall-back  
>>>>>> mechanism
>>>>>> to obtain consistent data.
>>>>> Well, ok, I imagine something like a revision counter. But I do  
>>>>> not see
>>>>> how it would work on an SMP system (kernel writing on one CPU,
>>>>> user-space reading on another cpu).
>>>> Ok, I had a look at seqlock.h, we can do it the same way, in an  
>>>> area of
>>>> the global heap. We will have to provide our own implementation  
>>>> since we
>>>> can not include linux/seqlock.h in user-space. update_vsyscall on  
>>>> x86_64
>>>> turns off the irqs, to protect against the same code or some reader
>>>> being called in an interrupt handler. We will have to do the same.
>>> But then the code can loop potentially unbounded, can't it? It may be
>>> that I'm missing something, but this was the initial reasaon for the
>>> three-buffer idea I've presented initially.
>> Well, on a normally running system, the update takes place for every
>> Linux timer interrupt (or is it only for the periodic tick ?), anyway,
>> if real-time code is running, there is no chance that it can be
>> preempted by a Linux timer interrupt, and if the code is called from  
>> non
>> real-time context, we do not care much.
> For a tickless System, it's only the periodic Tick, Not every Timer  
> Interrupt.
>> Note that we already use such code for tsc emulation on some  
>> platforms,
>> and well, it works. And this is normal, the chances to get preempted
>> several times in a row by a timer interrupt without being able to
>> complete the loop are pretty low. Otherwise it would mean that there  
>> are
>> plenty of timer interrupts.
> So that means, in essence, that you would accept probabilistic  
> algorithms in realtime context?

Ah, today's troll!

As I think I explained, the use of a seqlock in real-time context when
the seqlock writer only happens in linux context is not probabilistic.
It will work every time the first pass.

But other than that, yes, we do:
- RAM ECC algorithms only work for a given maximum number of bit changes
per cycle, and the source of bit changes is essentially random;
- cache behaviour, even though deterministic system-wise is
probabilistic from a real-time thread point of view, you never now how
many of your cache lines the non real-time threads will evict;
- fast user-space mutexes use compare-and-swap and retry if it failed
- user-space access to tsc on arm, powerpc, blackfin, nios, that is on
anything but x86 use a retry strategy.

We live with it.

The latency test allow you to measure the probabilistic effect of cache.

For the mutexes and tsc, if you happen to retry too often, it means that
the system starves the task which has the problem. It may be because you
designed your system that way, but in that case, you will expect it to
run slowly anyway, and it would be strange to specifically mandates the
mutex lock and tsc calls not to be slow. Or it may be because of a
design error, and in that case the design should be fixed, not mutex
lock and tsc.


Xenomai-core mailing list

Reply via email to