Re: [Xenomai-help] RT OS Selection advice for parallel processing

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

On 2011-02-03 12:49, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> On 2011-02-03 12:27, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> On 2011-02-03 12:04, Gilles Chanteperdrix wrote:
>>>>> Jan Kiszka wrote:
>>>>>> [ And, personally, I don't trust the NVIDIA driver a lot. But that might
>>>>>> be influenced by the fact that latest versions lock up my notebook
>>>>>> regularly after resume and that I filed another obvious locking issue of
>>>>>> the compilable driver stub around mmap_sem without any response from the
>>>>>> vendor. ]
>>>>> Some colleague of mine is using the NVIDIA driver (through the opengl
>>>>> mapping, not CUDA/VDPAU, whatever) on high-end NVIDIA boards in a non RT
>>>>> situation. he definitely observed some huge latencies not due to
>>>>> scheduling issues, when uploading textures to the GPU. We are talking
>>>>> tens of milliseconds here.
>>>> Ugh, tens of milliseconds is heavy, more than I would expect from
>>>> wbinvd. OTOH, uploading textures may involve mapping the RAM that
>>>> contains them for the GPU. To exclude that as source, he could try
>>>> instrumenting CACHE_FLUSH() (in nv-linux.h).
>>> No, it really looks like a bug in the blob. Of course the 40ms is a spot
>>> from time to time, usually, the upload is really fast.
>>
>> Unless it's a stall on the PCI bus, the blob should leaves some traces
>> in ftrace.
> 
> I am talking about the kernel-space blob. ftrance does just show that
> the ioctl has been submitted.

Function tracing takes you at least into the blob wrapper, both for
requests issued to the blob and for its callbacks to access Linux
services. It looks like NVIDIA as concentrating both arch and kernel
specific abstractions there, not in the blob (but that's just an
impression).

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux