xenomai.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
* while loop in a multi-core cpu
       [not found] ` <CAKcohPxHzbQvztgQMQaFq-EoXGbpfQxi1HpPV9nogBUaQ+PUSw@mail.gmail.com>
@ 2023-01-15 16:07   ` Yunjie Gu
  2023-01-16  3:05     ` Chen, Hongzhan
  0 siblings, 1 reply; 10+ messages in thread
From: Yunjie Gu @ 2023-01-15 16:07 UTC (permalink / raw)
  To: xenomai

Hi Guys,

We are trying to develop a polling mode thread to skip the delay of
the interrupt response. This is done by a while loop to check the
hardware (say a gpio or a timer) continuously. When we did this we
found that the system was frozen, meaning that the other cores are not
functioning when we run a polling loop on a single core. But if we do
the same in a normal Linux thread, the system is not frozen. I'm just
wondering if polling mode is allowed for xenomai, or if we did
anything incorrectly. A simple test piece of code to replicate this is
attached below. Our code runs on RaspberryPiCM4 (four-core ARM V7l)
with Linux 4.19 and xenomai 3.1.

Best Regards,
Yunjie

#include <stdio.h>
#include <unistd.h>
#include <alchemy/task.h>
#include <alchemy/timer.h>
#include <alchemy/sem.h>
#include <rtdm/uapi/rtdm.h>
#include <fcntl.h>
#include <linux/types.h>
#include <sys/ioctl.h>
#include <sys/mman.h>
RT_TASK demo_task;

void demo(void *arg)
{
    RT_TASK *curtask;
    RT_TASK_INFO curtaskinfo;

    curtask=rt_task_self();
    rt_task_inquire(curtask,&curtaskinfo);

    printf("Task name : %s \n", curtaskinfo.name);

        //------------------ hello world --------------------
    while (1)
    {
        printf("Hello World!\n");
    }

}

int main(int argc, char* argv[])
{
    char  str[10];

    // rt_print_auto_init(1);

    mlockall(MCL_CURRENT|MCL_FUTURE);

    printf("start task\n");

    sprintf(str,"hello");
    rt_task_create(&demo_task, str, 0, 50, 0);

    rt_task_start(&demo_task, &demo, 0);
    pause();
    rt_task_delete(&demo_task);
}

^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: while loop in a multi-core cpu
  2023-01-15 16:07   ` while loop in a multi-core cpu Yunjie Gu
@ 2023-01-16  3:05     ` Chen, Hongzhan
  2023-01-16  5:16       ` Jan Kiszka
  0 siblings, 1 reply; 10+ messages in thread
From: Chen, Hongzhan @ 2023-01-16  3:05 UTC (permalink / raw)
  To: Yunjie Gu, xenomai



>-----Original Message-----
>From: Yunjie Gu <yunjie.gu1@gmail.com>
>Sent: Monday, January 16, 2023 12:08 AM
>To: xenomai@lists.linux.dev
>Subject: while loop in a multi-core cpu
>
>Hi Guys,
>
>We are trying to develop a polling mode thread to skip the delay of
>the interrupt response. This is done by a while loop to check the
>hardware (say a gpio or a timer) continuously. When we did this we
>found that the system was frozen, meaning that the other cores are not
>functioning when we run a polling loop on a single core. But if we do
>the same in a normal Linux thread, the system is not frozen. I'm just
>wondering if polling mode is allowed for xenomai, or if we did

Xenomai threads should not dominate cpu too much time in dual kernel configuration.
When xenomai was dominating cpu too long time, from Linux 's view, cpu is like dead 
and Linux can not handle it correctly in such case.  If you enable CONFIG_XENO_OPT_WATCHDOG,
it may notify system to avoid such thing from debug point.

Regards

Hongzhan Chen 

>anything incorrectly. A simple test piece of code to replicate this is
>attached below. Our code runs on RaspberryPiCM4 (four-core ARM V7l)
>with Linux 4.19 and xenomai 3.1.
>
>Best Regards,
>Yunjie
>
>#include <stdio.h>
>#include <unistd.h>
>#include <alchemy/task.h>
>#include <alchemy/timer.h>
>#include <alchemy/sem.h>
>#include <rtdm/uapi/rtdm.h>
>#include <fcntl.h>
>#include <linux/types.h>
>#include <sys/ioctl.h>
>#include <sys/mman.h>
>RT_TASK demo_task;
>
>void demo(void *arg)
>{
>    RT_TASK *curtask;
>    RT_TASK_INFO curtaskinfo;
>
>    curtask=rt_task_self();
>    rt_task_inquire(curtask,&curtaskinfo);
>
>    printf("Task name : %s \n", curtaskinfo.name);
>
>        //------------------ hello world --------------------
>    while (1)
>    {
>        printf("Hello World!\n");
>    }
>
>}
>
>int main(int argc, char* argv[])
>{
>    char  str[10];
>
>    // rt_print_auto_init(1);
>
>    mlockall(MCL_CURRENT|MCL_FUTURE);
>
>    printf("start task\n");
>
>    sprintf(str,"hello");
>    rt_task_create(&demo_task, str, 0, 50, 0);
>
>    rt_task_start(&demo_task, &demo, 0);
>    pause();
>    rt_task_delete(&demo_task);
>}


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: while loop in a multi-core cpu
  2023-01-16  3:05     ` Chen, Hongzhan
@ 2023-01-16  5:16       ` Jan Kiszka
  2023-01-16  5:53         ` Chen, Hongzhan
  0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2023-01-16  5:16 UTC (permalink / raw)
  To: Chen, Hongzhan, Yunjie Gu, xenomai

On 16.01.23 04:05, Chen, Hongzhan wrote:
> 
> 
>> -----Original Message-----
>> From: Yunjie Gu <yunjie.gu1@gmail.com>
>> Sent: Monday, January 16, 2023 12:08 AM
>> To: xenomai@lists.linux.dev
>> Subject: while loop in a multi-core cpu
>>
>> Hi Guys,
>>
>> We are trying to develop a polling mode thread to skip the delay of
>> the interrupt response. This is done by a while loop to check the
>> hardware (say a gpio or a timer) continuously. When we did this we
>> found that the system was frozen, meaning that the other cores are not
>> functioning when we run a polling loop on a single core. But if we do
>> the same in a normal Linux thread, the system is not frozen. I'm just
>> wondering if polling mode is allowed for xenomai, or if we did
> 
> Xenomai threads should not dominate cpu too much time in dual kernel configuration.
> When xenomai was dominating cpu too long time, from Linux 's view, cpu is like dead 
> and Linux can not handle it correctly in such case.  If you enable CONFIG_XENO_OPT_WATCHDOG,
> it may notify system to avoid such thing from debug point.

Theoretically, a stable NOHZ-full setup should be able to tolerate on
top a Xenomai-only schedule with full CPU domination. However, achieving
that under Linux is already not trivial, and I haven't tested if Linux
is actually entering the right state when out-of-band Dovetail/Xenomai
takes over.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: while loop in a multi-core cpu
  2023-01-16  5:16       ` Jan Kiszka
@ 2023-01-16  5:53         ` Chen, Hongzhan
  2023-01-16  9:10           ` Jan Kiszka
  0 siblings, 1 reply; 10+ messages in thread
From: Chen, Hongzhan @ 2023-01-16  5:53 UTC (permalink / raw)
  To: Kiszka, Jan, Yunjie Gu, xenomai



>-----Original Message-----
>From: Jan Kiszka <jan.kiszka@siemens.com>
>Sent: Monday, January 16, 2023 1:17 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
><yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>Subject: Re: while loop in a multi-core cpu
>
>On 16.01.23 04:05, Chen, Hongzhan wrote:
>>
>>
>>> -----Original Message-----
>>> From: Yunjie Gu <yunjie.gu1@gmail.com>
>>> Sent: Monday, January 16, 2023 12:08 AM
>>> To: xenomai@lists.linux.dev
>>> Subject: while loop in a multi-core cpu
>>>
>>> Hi Guys,
>>>
>>> We are trying to develop a polling mode thread to skip the delay of
>>> the interrupt response. This is done by a while loop to check the
>>> hardware (say a gpio or a timer) continuously. When we did this we
>>> found that the system was frozen, meaning that the other cores are not
>>> functioning when we run a polling loop on a single core. But if we do
>>> the same in a normal Linux thread, the system is not frozen. I'm just
>>> wondering if polling mode is allowed for xenomai, or if we did
>>
>> Xenomai threads should not dominate cpu too much time in dual kernel
>configuration.
>> When xenomai was dominating cpu too long time, from Linux 's view, cpu is
>like dead
>> and Linux can not handle it correctly in such case.  If you enable
>CONFIG_XENO_OPT_WATCHDOG,
>> it may notify system to avoid such thing from debug point.
>
>Theoretically, a stable NOHZ-full setup should be able to tolerate on
>top a Xenomai-only schedule with full CPU domination. However, achieving
>that under Linux is already not trivial, and I haven't tested if Linux
>is actually entering the right state when out-of-band Dovetail/Xenomai
>takes over.

What do you means about NOHZ-full setup? Is it just related to configuration or commands passed for linux?
Is it possible to fix such issue that we do not need to modify Linux kernel?

Regards

Hongzhan Chen
>
>Jan
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: while loop in a multi-core cpu
  2023-01-16  5:53         ` Chen, Hongzhan
@ 2023-01-16  9:10           ` Jan Kiszka
  2023-01-16  9:13             ` Jan Kiszka
  0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2023-01-16  9:10 UTC (permalink / raw)
  To: Chen, Hongzhan, Yunjie Gu, xenomai

On 16.01.23 06:53, Chen, Hongzhan wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> Sent: Monday, January 16, 2023 1:17 PM
>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
>> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>> Subject: Re: while loop in a multi-core cpu
>>
>> On 16.01.23 04:05, Chen, Hongzhan wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Yunjie Gu <yunjie.gu1@gmail.com>
>>>> Sent: Monday, January 16, 2023 12:08 AM
>>>> To: xenomai@lists.linux.dev
>>>> Subject: while loop in a multi-core cpu
>>>>
>>>> Hi Guys,
>>>>
>>>> We are trying to develop a polling mode thread to skip the delay of
>>>> the interrupt response. This is done by a while loop to check the
>>>> hardware (say a gpio or a timer) continuously. When we did this we
>>>> found that the system was frozen, meaning that the other cores are not
>>>> functioning when we run a polling loop on a single core. But if we do
>>>> the same in a normal Linux thread, the system is not frozen. I'm just
>>>> wondering if polling mode is allowed for xenomai, or if we did
>>>
>>> Xenomai threads should not dominate cpu too much time in dual kernel
>> configuration.
>>> When xenomai was dominating cpu too long time, from Linux 's view, cpu is
>> like dead
>>> and Linux can not handle it correctly in such case.  If you enable
>> CONFIG_XENO_OPT_WATCHDOG,
>>> it may notify system to avoid such thing from debug point.
>>
>> Theoretically, a stable NOHZ-full setup should be able to tolerate on
>> top a Xenomai-only schedule with full CPU domination. However, achieving
>> that under Linux is already not trivial, and I haven't tested if Linux
>> is actually entering the right state when out-of-band Dovetail/Xenomai
>> takes over.
> 
> What do you means about NOHZ-full setup? Is it just related to configuration or commands passed for linux?
> Is it possible to fix such issue that we do not need to modify Linux kernel?
> 

I'm referring to
https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-clock-ticks-for-idle-cpus

If all works well in such a setup, a single(!) Linux userspace task can
run at 100% without being interrupted by any timers and other background
activity. Difference to Xenomai: If Linux finds out that the promise to
that task cannot be fulfilled, it simply interrupts it. But if that
should happen to a Xenomai task, Linux can't express that, and we would
be back to a deadlock situation.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: while loop in a multi-core cpu
  2023-01-16  9:10           ` Jan Kiszka
@ 2023-01-16  9:13             ` Jan Kiszka
  2023-01-16 14:09               ` Chen, Hongzhan
  0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2023-01-16  9:13 UTC (permalink / raw)
  To: Chen, Hongzhan, Yunjie Gu, xenomai

On 16.01.23 10:10, Jan Kiszka wrote:
> On 16.01.23 06:53, Chen, Hongzhan wrote:
>>
>>
>>> -----Original Message-----
>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>> Sent: Monday, January 16, 2023 1:17 PM
>>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
>>> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>>> Subject: Re: while loop in a multi-core cpu
>>>
>>> On 16.01.23 04:05, Chen, Hongzhan wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Yunjie Gu <yunjie.gu1@gmail.com>
>>>>> Sent: Monday, January 16, 2023 12:08 AM
>>>>> To: xenomai@lists.linux.dev
>>>>> Subject: while loop in a multi-core cpu
>>>>>
>>>>> Hi Guys,
>>>>>
>>>>> We are trying to develop a polling mode thread to skip the delay of
>>>>> the interrupt response. This is done by a while loop to check the
>>>>> hardware (say a gpio or a timer) continuously. When we did this we
>>>>> found that the system was frozen, meaning that the other cores are not
>>>>> functioning when we run a polling loop on a single core. But if we do
>>>>> the same in a normal Linux thread, the system is not frozen. I'm just
>>>>> wondering if polling mode is allowed for xenomai, or if we did
>>>>
>>>> Xenomai threads should not dominate cpu too much time in dual kernel
>>> configuration.
>>>> When xenomai was dominating cpu too long time, from Linux 's view, cpu is
>>> like dead
>>>> and Linux can not handle it correctly in such case.  If you enable
>>> CONFIG_XENO_OPT_WATCHDOG,
>>>> it may notify system to avoid such thing from debug point.
>>>
>>> Theoretically, a stable NOHZ-full setup should be able to tolerate on
>>> top a Xenomai-only schedule with full CPU domination. However, achieving
>>> that under Linux is already not trivial, and I haven't tested if Linux
>>> is actually entering the right state when out-of-band Dovetail/Xenomai
>>> takes over.
>>
>> What do you means about NOHZ-full setup? Is it just related to configuration or commands passed for linux?
>> Is it possible to fix such issue that we do not need to modify Linux kernel?
>>
> 
> I'm referring to
> https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-clock-ticks-for-idle-cpus
> 

Actually:
https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-clock-ticks-for-cpus-with-only-one-runnable-task

> If all works well in such a setup, a single(!) Linux userspace task can
> run at 100% without being interrupted by any timers and other background
> activity. Difference to Xenomai: If Linux finds out that the promise to
> that task cannot be fulfilled, it simply interrupts it. But if that
> should happen to a Xenomai task, Linux can't express that, and we would
> be back to a deadlock situation.
> 
> Jan
> 

-- 
Siemens AG, Technology
Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

* RE: while loop in a multi-core cpu
  2023-01-16  9:13             ` Jan Kiszka
@ 2023-01-16 14:09               ` Chen, Hongzhan
  2023-01-16 14:20                 ` Jan Kiszka
  0 siblings, 1 reply; 10+ messages in thread
From: Chen, Hongzhan @ 2023-01-16 14:09 UTC (permalink / raw)
  To: Kiszka, Jan, Yunjie Gu, xenomai



>-----Original Message-----
>From: Jan Kiszka <jan.kiszka@siemens.com>
>Sent: Monday, January 16, 2023 5:13 PM
>To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
><yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>Subject: Re: while loop in a multi-core cpu
>
>On 16.01.23 10:10, Jan Kiszka wrote:
>> On 16.01.23 06:53, Chen, Hongzhan wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>> Sent: Monday, January 16, 2023 1:17 PM
>>>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
>>>> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>>>> Subject: Re: while loop in a multi-core cpu
>>>>
>>>> On 16.01.23 04:05, Chen, Hongzhan wrote:
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Yunjie Gu <yunjie.gu1@gmail.com>
>>>>>> Sent: Monday, January 16, 2023 12:08 AM
>>>>>> To: xenomai@lists.linux.dev
>>>>>> Subject: while loop in a multi-core cpu
>>>>>>
>>>>>> Hi Guys,
>>>>>>
>>>>>> We are trying to develop a polling mode thread to skip the delay of
>>>>>> the interrupt response. This is done by a while loop to check the
>>>>>> hardware (say a gpio or a timer) continuously. When we did this we
>>>>>> found that the system was frozen, meaning that the other cores are not
>>>>>> functioning when we run a polling loop on a single core. But if we do
>>>>>> the same in a normal Linux thread, the system is not frozen. I'm just
>>>>>> wondering if polling mode is allowed for xenomai, or if we did
>>>>>
>>>>> Xenomai threads should not dominate cpu too much time in dual kernel
>>>> configuration.
>>>>> When xenomai was dominating cpu too long time, from Linux 's view,
>cpu is
>>>> like dead
>>>>> and Linux can not handle it correctly in such case.  If you enable
>>>> CONFIG_XENO_OPT_WATCHDOG,
>>>>> it may notify system to avoid such thing from debug point.
>>>>
>>>> Theoretically, a stable NOHZ-full setup should be able to tolerate on
>>>> top a Xenomai-only schedule with full CPU domination. However,
>achieving
>>>> that under Linux is already not trivial, and I haven't tested if Linux
>>>> is actually entering the right state when out-of-band Dovetail/Xenomai
>>>> takes over.
>>>
>>> What do you means about NOHZ-full setup? Is it just related to
>configuration or commands passed for linux?
>>> Is it possible to fix such issue that we do not need to modify Linux kernel?
>>>
>>
>> I'm referring to
>> https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-
>scheduling-clock-ticks-for-idle-cpus
>>
>
>Actually:
>https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-
>clock-ticks-for-cpus-with-only-one-runnable-task

The last paragraph of known issues in https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-
clock-ticks-for-cpus-with-only-one-runnable-task, it mentioned that there is still the needs which 
are are currently accommodated by scheduling-clock tick every second or so including calculating CPU load, maintaining sched average, computing CFS entity vruntime, computing avenrun, and carrying out load balancing.
If we can not meet these needs , may it cause other system issue?
In dpdk, we may also need 100% dominating cpu in PMD mode, it is worth giving it a try.

Regards

Hongzhan Chen



>> If all works well in such a setup, a single(!) Linux userspace task can
>> run at 100% without being interrupted by any timers and other background
>> activity. Difference to Xenomai: If Linux finds out that the promise to
>> that task cannot be fulfilled, it simply interrupts it. But if that
>> should happen to a Xenomai task, Linux can't express that, and we would
>> be back to a deadlock situation.
>>
>> Jan
>>
>
>--
>Siemens AG, Technology
>Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: while loop in a multi-core cpu
  2023-01-16 14:09               ` Chen, Hongzhan
@ 2023-01-16 14:20                 ` Jan Kiszka
  2023-01-17  9:50                   ` Yunjie Gu
  0 siblings, 1 reply; 10+ messages in thread
From: Jan Kiszka @ 2023-01-16 14:20 UTC (permalink / raw)
  To: Chen, Hongzhan, Yunjie Gu, xenomai

On 16.01.23 15:09, Chen, Hongzhan wrote:
> 
> 
>> -----Original Message-----
>> From: Jan Kiszka <jan.kiszka@siemens.com>
>> Sent: Monday, January 16, 2023 5:13 PM
>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
>> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>> Subject: Re: while loop in a multi-core cpu
>>
>> On 16.01.23 10:10, Jan Kiszka wrote:
>>> On 16.01.23 06:53, Chen, Hongzhan wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
>>>>> Sent: Monday, January 16, 2023 1:17 PM
>>>>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
>>>>> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
>>>>> Subject: Re: while loop in a multi-core cpu
>>>>>
>>>>> On 16.01.23 04:05, Chen, Hongzhan wrote:
>>>>>>
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Yunjie Gu <yunjie.gu1@gmail.com>
>>>>>>> Sent: Monday, January 16, 2023 12:08 AM
>>>>>>> To: xenomai@lists.linux.dev
>>>>>>> Subject: while loop in a multi-core cpu
>>>>>>>
>>>>>>> Hi Guys,
>>>>>>>
>>>>>>> We are trying to develop a polling mode thread to skip the delay of
>>>>>>> the interrupt response. This is done by a while loop to check the
>>>>>>> hardware (say a gpio or a timer) continuously. When we did this we
>>>>>>> found that the system was frozen, meaning that the other cores are not
>>>>>>> functioning when we run a polling loop on a single core. But if we do
>>>>>>> the same in a normal Linux thread, the system is not frozen. I'm just
>>>>>>> wondering if polling mode is allowed for xenomai, or if we did
>>>>>>
>>>>>> Xenomai threads should not dominate cpu too much time in dual kernel
>>>>> configuration.
>>>>>> When xenomai was dominating cpu too long time, from Linux 's view,
>> cpu is
>>>>> like dead
>>>>>> and Linux can not handle it correctly in such case.  If you enable
>>>>> CONFIG_XENO_OPT_WATCHDOG,
>>>>>> it may notify system to avoid such thing from debug point.
>>>>>
>>>>> Theoretically, a stable NOHZ-full setup should be able to tolerate on
>>>>> top a Xenomai-only schedule with full CPU domination. However,
>> achieving
>>>>> that under Linux is already not trivial, and I haven't tested if Linux
>>>>> is actually entering the right state when out-of-band Dovetail/Xenomai
>>>>> takes over.
>>>>
>>>> What do you means about NOHZ-full setup? Is it just related to
>> configuration or commands passed for linux?
>>>> Is it possible to fix such issue that we do not need to modify Linux kernel?
>>>>
>>>
>>> I'm referring to
>>> https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-
>> scheduling-clock-ticks-for-idle-cpus
>>>
>>
>> Actually:
>> https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-
>> clock-ticks-for-cpus-with-only-one-runnable-task
> 
> The last paragraph of known issues in https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-
> clock-ticks-for-cpus-with-only-one-runnable-task, it mentioned that there is still the needs which 
> are are currently accommodated by scheduling-clock tick every second or so including calculating CPU load, maintaining sched average, computing CFS entity vruntime, computing avenrun, and carrying out load balancing.
> If we can not meet these needs , may it cause other system issue?
> In dpdk, we may also need 100% dominating cpu in PMD mode, it is worth giving it a try.
> 

Yeah, didn't check in a while that status, just recalling the at least
mainline was not able to provide 100%, but there were concepts (or
hacks?) to get it at that level. Obviously, if there is still no 100% in
mainline, we would just prolong the phase of CPU domination also for
Xenomai tasks, but not eliminate the need to periodically release it for
a while.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: while loop in a multi-core cpu
  2023-01-16 14:20                 ` Jan Kiszka
@ 2023-01-17  9:50                   ` Yunjie Gu
  2023-01-17  9:57                     ` Jan Kiszka
  0 siblings, 1 reply; 10+ messages in thread
From: Yunjie Gu @ 2023-01-17  9:50 UTC (permalink / raw)
  To: Jan Kiszka; +Cc: Chen, Hongzhan, xenomai, qiyu_sjtu

Hi Hongzhan and Jan,

Many thanks for the answers. Is this also true even for multi-core
cpus? When one of the cores is running a xenomai thread 100%, what the
other cores are doing?
If we really want a core to run a 100% while loop, how can we do that
in a dual-core xenomai system? Say, can we isolate one core that is
not managed by the OS (i.e. kind of bare-metal) to do this?

Best Regards,
Yunjie

On Mon, 16 Jan 2023 at 14:20, Jan Kiszka <jan.kiszka@siemens.com> wrote:
>
> On 16.01.23 15:09, Chen, Hongzhan wrote:
> >
> >
> >> -----Original Message-----
> >> From: Jan Kiszka <jan.kiszka@siemens.com>
> >> Sent: Monday, January 16, 2023 5:13 PM
> >> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
> >> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
> >> Subject: Re: while loop in a multi-core cpu
> >>
> >> On 16.01.23 10:10, Jan Kiszka wrote:
> >>> On 16.01.23 06:53, Chen, Hongzhan wrote:
> >>>>
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Jan Kiszka <jan.kiszka@siemens.com>
> >>>>> Sent: Monday, January 16, 2023 1:17 PM
> >>>>> To: Chen, Hongzhan <hongzhan.chen@intel.com>; Yunjie Gu
> >>>>> <yunjie.gu1@gmail.com>; xenomai@lists.linux.dev
> >>>>> Subject: Re: while loop in a multi-core cpu
> >>>>>
> >>>>> On 16.01.23 04:05, Chen, Hongzhan wrote:
> >>>>>>
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Yunjie Gu <yunjie.gu1@gmail.com>
> >>>>>>> Sent: Monday, January 16, 2023 12:08 AM
> >>>>>>> To: xenomai@lists.linux.dev
> >>>>>>> Subject: while loop in a multi-core cpu
> >>>>>>>
> >>>>>>> Hi Guys,
> >>>>>>>
> >>>>>>> We are trying to develop a polling mode thread to skip the delay of
> >>>>>>> the interrupt response. This is done by a while loop to check the
> >>>>>>> hardware (say a gpio or a timer) continuously. When we did this we
> >>>>>>> found that the system was frozen, meaning that the other cores are not
> >>>>>>> functioning when we run a polling loop on a single core. But if we do
> >>>>>>> the same in a normal Linux thread, the system is not frozen. I'm just
> >>>>>>> wondering if polling mode is allowed for xenomai, or if we did
> >>>>>>
> >>>>>> Xenomai threads should not dominate cpu too much time in dual kernel
> >>>>> configuration.
> >>>>>> When xenomai was dominating cpu too long time, from Linux 's view,
> >> cpu is
> >>>>> like dead
> >>>>>> and Linux can not handle it correctly in such case.  If you enable
> >>>>> CONFIG_XENO_OPT_WATCHDOG,
> >>>>>> it may notify system to avoid such thing from debug point.
> >>>>>
> >>>>> Theoretically, a stable NOHZ-full setup should be able to tolerate on
> >>>>> top a Xenomai-only schedule with full CPU domination. However,
> >> achieving
> >>>>> that under Linux is already not trivial, and I haven't tested if Linux
> >>>>> is actually entering the right state when out-of-band Dovetail/Xenomai
> >>>>> takes over.
> >>>>
> >>>> What do you means about NOHZ-full setup? Is it just related to
> >> configuration or commands passed for linux?
> >>>> Is it possible to fix such issue that we do not need to modify Linux kernel?
> >>>>
> >>>
> >>> I'm referring to
> >>> https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-
> >> scheduling-clock-ticks-for-idle-cpus
> >>>
> >>
> >> Actually:
> >> https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-
> >> clock-ticks-for-cpus-with-only-one-runnable-task
> >
> > The last paragraph of known issues in https://www.kernel.org/doc/html/latest/timers/no_hz.html#omit-scheduling-
> > clock-ticks-for-cpus-with-only-one-runnable-task, it mentioned that there is still the needs which
> > are are currently accommodated by scheduling-clock tick every second or so including calculating CPU load, maintaining sched average, computing CFS entity vruntime, computing avenrun, and carrying out load balancing.
> > If we can not meet these needs , may it cause other system issue?
> > In dpdk, we may also need 100% dominating cpu in PMD mode, it is worth giving it a try.
> >
>
> Yeah, didn't check in a while that status, just recalling the at least
> mainline was not able to provide 100%, but there were concepts (or
> hacks?) to get it at that level. Obviously, if there is still no 100% in
> mainline, we would just prolong the phase of CPU domination also for
> Xenomai tasks, but not eliminate the need to periodically release it for
> a while.
>
> Jan
>
> --
> Siemens AG, Technology
> Competence Center Embedded Linux
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: while loop in a multi-core cpu
  2023-01-17  9:50                   ` Yunjie Gu
@ 2023-01-17  9:57                     ` Jan Kiszka
  0 siblings, 0 replies; 10+ messages in thread
From: Jan Kiszka @ 2023-01-17  9:57 UTC (permalink / raw)
  To: Yunjie Gu; +Cc: Chen, Hongzhan, xenomai, qiyu_sjtu

On 17.01.23 10:50, Yunjie Gu wrote:
> Hi Hongzhan and Jan,
> 
> Many thanks for the answers. Is this also true even for multi-core
> cpus? When one of the cores is running a xenomai thread 100%, what the
> other cores are doing?

NO_HZ_FULL only works on multicore - you can't operate a complete Linux
system with only a single runnable task.

> If we really want a core to run a 100% while loop, how can we do that
> in a dual-core xenomai system? Say, can we isolate one core that is
> not managed by the OS (i.e. kind of bare-metal) to do this?

An architectural alternative to using 100%-tasks under Linux is applying
a hypervisor and running that task on an isolated core bare-metal.
Jailhouse (https:github.com/siemens/jailhouse) is one example for such
an hypervisor. That comes with its own pros and cons, though.

Jan

-- 
Siemens AG, Technology
Competence Center Embedded Linux


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-01-17  9:57 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1673779013-11742-mlmmj-00f27513@lists.linux.dev>
     [not found] ` <CAKcohPxHzbQvztgQMQaFq-EoXGbpfQxi1HpPV9nogBUaQ+PUSw@mail.gmail.com>
2023-01-15 16:07   ` while loop in a multi-core cpu Yunjie Gu
2023-01-16  3:05     ` Chen, Hongzhan
2023-01-16  5:16       ` Jan Kiszka
2023-01-16  5:53         ` Chen, Hongzhan
2023-01-16  9:10           ` Jan Kiszka
2023-01-16  9:13             ` Jan Kiszka
2023-01-16 14:09               ` Chen, Hongzhan
2023-01-16 14:20                 ` Jan Kiszka
2023-01-17  9:50                   ` Yunjie Gu
2023-01-17  9:57                     ` Jan Kiszka

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).