sched/sleep: replace all Signal-based sleep implement to Scheduled sleep

[anchao]

Summary

Continuous work of #17200

sched/sleep: replace all Signal-based sleep implement to Scheduled sleep

Nuttx currently has 2 types of sleep interfaces:

1. Signal-scheduled sleep: nxsig_sleep() / nxsig_usleep() / nxsig_nanosleep()
   Weaknesses:
   a. Signal-dependent: The signal-scheduled sleep method is bound to the signal framework, while some driver sleep operations do not depend on signals.
   b. Timespec conversion: Signal-scheduled sleep involves timespec conversion, which has a significant impact on performance.

2. Busy sleep: up_mdelay() / up_udelay()
   Weaknesses:
   a. Does not actively trigger scheduling, occupy the CPU loading.

3. New interfaces: Scheduled sleep: nxsched_sleep() / nxsched_usleep() / nxsched_msleep() / nxsched_ticksleep()
   Strengths:
   a. Does not depend on the signal framework.
   b. Tick-based, without additional computational overhead.

Currently, the Nuttx driver framework extensively uses nxsig_* interfaces. However, the driver does not need to rely on signals or timespec conversion.
Therefore, a new set of APIs is added to reduce dependencies on other modules.

(This PR also aims to make signals optional, further reducing the code size of Nuttx.)

Signed-off-by: chao an anchao.archer@bytedance.com

Impact

N/A

Testing

new api test on sim/nsh, sabre-6quad/smp:

nxsched_sleep() / nxsched_usleep() / nxsched_msleep() / nxsched_ticksleep()

[fdcavalcanti]

How did you test this? Can you share?

[anchao]

How did you test this? Can you share?

@fdcavalcanti
In our internal projects, some drivers make extensive use of the sleep interface.
In the nuttx project, I tested 2 configurations: sim/nsh and sabre-6quad/smp. I also have a simplified test code:

int main(int argc, FAR char *argv[])
{
  syslog(1, "Hello, World!!\n");
  nxsched_msleep(1000);
  syslog(1, "Hello, World!!\n");
  nxsched_usleep(1000 * 1000); 
  syslog(1, "Hello, World!!\n");
  nxsched_sleep(1);
  syslog(1, "Hello, World!!\n");
  return 0;
}

here is output:

$ qemu-system-arm -semihosting -M sabrelite -m 1024 -smp 4 -nographic -kernel ./nuttx

NuttShell (NSH) NuttX-10.4.0
nsh> hello
[    1.280000] [CPU1] Hello, World!!
[    2.290000] [CPU0] Hello, World!!
[    3.300000] [CPU0] Hello, World!!
[    4.310000] [CPU0] Hello, World!!
nsh>

could you help test the ESP chip? Some replacements may affect the ESP driver behavior.

[fdcavalcanti]

How did you test this? Can you share?

@fdcavalcanti In our internal projects, some drivers make extensive use of the sleep interface. In the nuttx project, I tested 2 configurations: sim/nsh and sabre-6quad/smp. I also have a simplified test code:

int main(int argc, FAR char *argv[])
{
  syslog(1, "Hello, World!!\n");
  nxsched_msleep(1000);
  syslog(1, "Hello, World!!\n");
  nxsched_usleep(1000 * 1000); 
  syslog(1, "Hello, World!!\n");
  nxsched_sleep(1);
  syslog(1, "Hello, World!!\n");
  return 0;
}

here is output:

$ qemu-system-arm -semihosting -M sabrelite -m 1024 -smp 4 -nographic -kernel ./nuttx

NuttShell (NSH) NuttX-10.4.0
nsh> hello
[    1.280000] [CPU1] Hello, World!!
[    2.290000] [CPU0] Hello, World!!
[    3.300000] [CPU0] Hello, World!!
[    4.310000] [CPU0] Hello, World!!
nsh>

could you help test the ESP chip? Some replacements may affect the ESP driver behavior.

I will run our internal CI, please don't merge for a while.

[linguini1]

I like the new interface, but I'm not confident about changing all the calls to nxsig_sleep. It will be hard to test all of those drivers, and sometimes the difference in timing between sleep implementations can cause issues. I think this should just be the interface used going forward, and drivers can be swapped out one by one when they're able to be tested. I'm worried this will break some drivers and there's no testing for those.

[anchao]

I like the new interface, but I'm not confident about changing all the calls to nxsig_sleep. It will be hard to test all of those drivers, and sometimes the difference in timing between sleep implementations can cause issues. I think this should just be the interface used going forward, and drivers can be swapped out one by one when they're able to be tested. I'm worried this will break some drivers and there's no testing for those.

The intent of this change is to make the signal framework configurable, as most RTOS devices don't require signal support and it would be too burdensome for an RTOS environment.

If a complete replacement isn't made at this stage, the driver and BSP code will still rely on signal.

In addition, the replacement of sleep-related implementations will not bring any impact. The implementation details of nxsched_* and nxsig_* is similar.

[fdcavalcanti]

Look good to me.

[linguini1]

One more question: if this replaces all the nxsig_sleep calls, doesn't that make the function obsolete? What's the use case for nxsig_sleep versus this new tick-based method?

[anchao]

One more question: if this replaces all the nxsig_sleep calls, doesn't that make the function obsolete? What's the use case for nxsig_sleep versus this new tick-based method?

@linguini1

nxsig_sleep/usleep has the following two features:

1. Supports the processing of signal sets.
   https://github.com/apache/nuttx/blob/master/sched/signal/sig_timedwait.c#L98-L108
2. Supports cancellation points.
   https://github.com/apache/nuttx/blob/master/sched/signal/sig_timedwait.c#L275-L289

Both of the above features are mandatory requirements of POSIX, so we cannot remove them.

nxsig_sleep/usleep is the internal implementation of POSIX API sleep/usleep, and userspace needs to follow the semantics of POSIX.

https://pubs.opengroup.org/onlinepubs/009696799/functions/sleep.html

The sleep() function shall cause the calling thread to be suspended from execution until either the number of realtime seconds specified by the argument seconds has elapsed or a signal is delivered to the calling thread and its action is to invoke a signal-catching function or to terminate the process.

[linguini1]

Thank you for the clarification @anchao and sorry for the basic questions! That makes much more sense to me now.

[linguini1]

I guess it might be a good idea to document somewhere that driver implementations should use this new API to avoid mixing nxsig* back into driver code.