Cache Manager Functions with Processor Set

[Sebastian Huber]

On 16/09/14 16:00, Daniel Hellstrom wrote:
> On 09/16/2014 02:23 PM, Sebastian Huber wrote:
>> 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.
>
> That sounds better.
>
> When you say modern processors do that automatically, do you mean even for L2
> and L3 caches?

The higher level caches are usually inclusive unified caches, so yes unless you 
want to make it painful for the user.

>
>>>>
>>>> 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.
>
> Is it common for SMP operating systems not to have the ability to
> flush/invalidate its local CPU? DMA is one reason.

I think your emphasis on local CPUs is artificial.  The concept of SMP is to 
share data with low overhead on multiple processors.

> In the optimization case you
> mention it wouldn't be that hard to use the platform specific alternative instead?

Yes, I would prefer to use platform specific functions to do such a 
non-portable stuff that is pretty easy to get wrong.

>
>
>>>> 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?
>
> I can't see any particular use case for doing these operation on a set of CPUs.
> One or all CPUs is what I see. If you want to remove them its fine by me, what
> I'm trying to say I guess is that it doesn't cost that much to have them
> around. Since they depend on the local-cpu cache operations anyway, and we
> still need the IPI handler for the all-cpu operations.
>
> Daniel

I am perfectly fine with the _Cache_manager_Send_smp_msg() method in general. 
I have a problem with exposing this complicated processor set specific cache 
functions to users via rtems_cache_*() functions.  It a lot safer to simply do 
a global flush/invalidate.

-- 
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.