Cache Manager Functions with Processor Set

[Sebastian Huber]

On 16/09/14 14:10, Daniel Hellstrom wrote:
> On 09/16/2014 01:49 PM, Sebastian Huber wrote:
>> On 16/09/14 13:42, Daniel Hellstrom wrote:
>>>> Hello,
>>>>
>>>> what is the use case for the following functions:
>>>>
>>>> rtems_cache_flush_multiple_data_lines_processor_set()
>>>>
>>>> rtems_cache_invalidate_multiple_data_lines_processor_set()
>>>>
>>>> rtems_cache_flush_entire_data_processor_set()
>>>>
>>>> rtems_cache_invalidate_entire_data_processor_set()
>>>>
>>>> ?
>>>>
>>>> Makes it sense on an SMP system running an operating system and application
>>>> in one address space to do processor specific cache operations?
>>>>
>>>> The functions are currently unused (except for the test program).
>>>
>>> I think most likely we want to flush/invalidate all CPUs in the system or only
>>> the local CPU's cache. Why do you ask, have you found a reason to limit/change
>>> the API?
>>
>> For all CPUs, you have the standard functions.
>
> You mean the standard function should operate on all CPUs? That would change
> the behaviour on SMP, but is probably what the user wants? You mean to add add
> cpu_local flush API next to the standard functions?

Yes, of course the standard functions should operate on all processors.  We 
have symmetric multiprocessing.  The cache operations on modern processors do 
this automatically.

>
>>
>> The usage of "local CPU" is extremely dangerous since this makes only sense
>> if you are absolutely sure that you stay on the current processor long enough.
> It might be dangerous, but we need that ability. Isn't it only to disable
> global interrupt and then it is safe, or when CPU affinity is used we could
> know that we're always executing on the same CPU?

Yes, but you must also guarantee that the data producer/consumer is also 
exactly this processor.

Can you please give me an example, why you need this ability?  For me this 
looks like an optimization for one particular special case on one particular 
hardware.

>
>>
>> I am in favour of removing these new API calls in case there is no strong use
>> case.
>
> What is the reason for that, footprint, ease BSP support etc?

We should not make it too hard for the users.  I think it is too difficult to 
use these functions.  They are also fairly non-standard.  Which other operating 
system offers functions to do cache synchronization on a subset of processors?

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.