libBSD and CPU Load display questions in SMP mode
Chris Johns
chrisj at rtems.org
Wed Oct 17 05:59:28 UTC 2018
On 17/10/18 4:05 pm, Sebastian Huber wrote:
> On 17/10/2018 02:46, Chris Johns wrote:
>> On 16/10/2018 19:34, Sebastian Huber wrote:
>>> On 16/10/2018 10:28, jameszxj wrote:
>>>> CPU:zynq z7020 RTEMS version: master version
>>>> SMP define:
>>>> #define CONFIGURE_MAXIMUM_PROCESSORS 2
>>>>
>>>> #if 1
>>>> #define CONFIGURE_MAXIMUM_PRIORITY 255
>>>>
>>>> #define CONFIGURE_SCHEDULER_PRIORITY_SMP
>>> The only SMP scheduler supported by libbsd is:
>>>
>>> #define CONFIGURE_SCHEDULER_EDF_SMP
>> Why does the restriction exist?
>
> This SMP scheduler implementation is the only one in RTEMS that supports thread
> pinning. It is the default scheduler.
The documentation says:
In case no explicit clustered scheduler configuration is present, then it
is used as the scheduler for exactly one processor.
I do not know what this means. I see the default is mentioned just after this. I
wonder if a section about the defaults in either 24.21 and/or 24.22?
The clustered scheduling section has:
A clustered scheduler configuration is optional. By default, up to 32
processors are managed by the EDF SMP Scheduler.
It is not clear if the default is 32 processors, the scheduler or both.
> A clustered scheduler configuration is
> optional and should be done only for very good reasons.
Sure.
>
>>
>>>> 2.when I connect to RTEMS with ftp or telnet, system reset.
>>>> If just only define CONFIGURE_MAXIMUM_PROCESSORS,ftp and telnet is ok.
>>>>
>>>> *** FATAL ***
>>>> fatal source: 10 (RTEMS_FATAL_SOURCE_SMP)
>>>> fatal code: 7 (0x00000007)
>>> This is:
>>>
>>> SMP_FATAL_SCHEDULER_PIN_OR_UNPIN_NOT_SUPPORTED
>>>
>> Who is pinning threads?
>
> Thread pinning
>
> https://docs.rtems.org/branches/master/c-user/symmetric_multiprocessing_services.html#thread-pinning
>
>
> is used by the Epoch Based Reclamation (EBR) implementation:
>
> https://git.rtems.org/rtems-libbsd/tree/rtemsbsd/rtems/rtems-kernel-epoch.c
>
OK. Does FreeBSD pin threads as well?
Chris
More information about the devel
mailing list