Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?


"曹子龙
 


Hi everyone:

  whey the SMP version of zephyr kernel idle task has involke the "k_busy_wait"? and it is especially unreasonable to pass the delay time with 100.
why not 200, 300, 400..... and so on?

i cant very catch the comment with reason " to prevent the lock condentation"  if there are  lock condention exists, can the contention corner case be avoided just with a deay time??
i just cant understand the present implementation
thanks for your kindly help.

void idle(void *unused1, void *unused2, void *unused3)
{
    ARG_UNUSED(unused1);
    ARG_UNUSED(unused2);
    ARG_UNUSED(unused3);


    while (true) {
        k_busy_wait(100);
        k_yield();
    }

曹子龙

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 



Boie, Andrew P
 

There’s an open bug for this:

 

https://github.com/zephyrproject-rtos/zephyr/issues/6157

 

Andrew

 

From: devel@... <devel@...> On Behalf Of "???
Sent: Sunday, August 4, 2019 4:04 PM
To: devel <devel@...>
Subject: [Zephyr-devel] Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

 

 

Hi everyone:

 

  whey the SMP version of zephyr kernel idle task has involke the "k_busy_wait"? and it is especially unreasonable to pass the delay time with 100.

why not 200, 300, 400..... and so on?

 

i cant very catch the comment with reason " to prevent the lock condentation"  if there are  lock condention exists, can the contention corner case be avoided just with a deay time??

i just cant understand the present implementation

thanks for your kindly help.

 

void idle(void *unused1, void *unused2, void *unused3)
{
    ARG_UNUSED(unused1);
    ARG_UNUSED(unused2);
    ARG_UNUSED(unused3);

 

 

    while (true) {
        k_busy_wait(100);
        k_yield();
    }

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com

 

 


Andy Ross
 

FWIW: the reason for the busy wait is to reduce the number of calls to k_yield() which needs to enter the scheduler and obviously take a spinlock for synchronization.  If you have one CPU spinning on the scheduler lock, the other is going to constantly have to contend for it and you get a performance disaster.


FWIW: we have an IPI framework now.  This is straightforward to fix.


Andy


On 8/4/19 5:41 PM, Boie, Andrew P wrote:

There’s an open bug for this:

 

https://github.com/zephyrproject-rtos/zephyr/issues/6157

 

Andrew

 

From: devel@... <devel@...> On Behalf Of "???
Sent: Sunday, August 4, 2019 4:04 PM
To: devel <devel@...>
Subject: [Zephyr-devel] Why the smp version of zephyr kernel "idle" task implent the "k_busy_wait(100)" delay?

 

 

Hi everyone:

 

  whey the SMP version of zephyr kernel idle task has involke the "k_busy_wait"? and it is especially unreasonable to pass the delay time with 100.

why not 200, 300, 400..... and so on?

 

i cant very catch the comment with reason " to prevent the lock condentation"  if there are  lock condention exists, can the contention corner case be avoided just with a deay time??

i just cant understand the present implementation

thanks for your kindly help.

 

void idle(void *unused1, void *unused2, void *unused3)
{
    ARG_UNUSED(unused1);
    ARG_UNUSED(unused2);
    ARG_UNUSED(unused3);

 

 

    while (true) {
        k_busy_wait(100);
        k_yield();
    }

 

曹子

珠海全志科技股份有限公司      BU1-PSW

地址:广东省珠海市高新区唐家湾镇科技2路9号

TEL:13824125580

Email:caozilong@...

网址: http://www.allwinnertech.com