Post by Daniel HellstromPost by Sebastian HuberPost by Daniel HellstromPost by Sebastian HuberPost by Daniel HellstromPost by Sebastian HuberHello,
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.
Post by Daniel HellstromPost by Sebastian HuberPost by Daniel HellstromPost by Sebastian HuberThe 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.
Post by Daniel HellstromIn 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.
Post by Daniel HellstromPost by Sebastian HuberPost by Daniel HellstromPost by Sebastian HuberI 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 : ***@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.