cpuset macro /vs/ inline implementation

[Sebastian Huber]

On 2013-10-31 13:21, Daniel Hellstrom wrote:
> On 10/31/2013 12:38 PM, Sebastian Huber wrote:
>> On 2013-10-31 12:30, Daniel Hellstrom wrote:
>>> I see that the cpu_set_word_t is set to 32-bit which suites most CPUs, there is
>>> probably a good reason for it but would it make sens to make it dependent on
>>> the architecture? So that 64-bit machines have it sized to 64-bits. I'm not
>>> sure there are 16-bit SMP machines :) .
>>
>> No, this should be a fixed size integer for all architectures to allow static
>> initialization.  Anyway it will be a long way for RTEMS to support 33
>> processors.
>
> So what is the point of having an array of 32-bits in the set? If there were a
> 16-bit SMP CPU would not performance be better to describe it with a 16-bit
> instead of an 32-bit word? Its probably not realistic with a 16-bit SMP machine
> anyway, more realistic is a 64-bit SMP machine. Would the atomicity of having a
> 64-bit word instead of 32-bit word on a 64-bit machine matter?

Performance of the operations at this API level is completely irrelevant.  What 
the implementation does with these CPU sets internally is something different.

Other operating systems don't have a static link-time configuration.

> At this point we
> haven't been discussing atomic cpusets, my guess is that other OSes have
> definitions for that and in that case on a 64-bit machine it could make sens,
> or what do you think?

What do you mean with "atomic cpusets".

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