core: Scheduler and IPC as modules

[maribu]

Description

RIOT's scheduler and IPC has been developed with an eye on code size. Nonetheless, applications only using a single thread have no need for them. In this specific scenario the overhead of the scheduler, the idle thread and IPC could be avoided.

This issue is intended to discuss if downgrading core features of RIOT to optional modules is acceptable and worth the effort. Feel free to extend the list of pros and cons.

Pros

• The minimum resource requirements of RIOT could be significantly lowered
  • This would likely result in RIOT beating TinyOS's minimal resource requirements 😄
  • Allow building many more apps in test/ for the most constrained boards
  • Debunk the "Arduino is better for trival tasks because of resource requirements" argument, which is itching me a lot

Cons

• Could be significant effort to achieve
• A lot of apps will need to add USEMODULE += multitasking (or what ever the syntax of adding the previously non-optional features will be)

Implementation Details

If this is considered to be worthwhile, how should this be implemented?

• Keep everything in core non-optional and move multitasking support to sys, to keep the current code architecture?

[miri64]

This might be seen as related: #10971 (though I still use the scheduler for the idle thread there).

[maribu]

@miri64: Yes, indeed. Making the main thread optional will cut down most of the overhead the approach suggested here would remove, but is likely less invasive. On the other hand dropping the idle thread and scheduler would likely be applicable to the use cases #10971 has in mind and also others that do require a main thread.

[miri64]

On the other hand dropping the idle thread and scheduler would likely be applicable to the use cases #10971 has in mind and also others that do require a main thread.

Since the device in that use case was battery operated, I relied on the idle thread put the device to sleep. So I'm not sure that dropping the idle thread would have been what I wanted in that case.

[maribu]

The main thread would need to be doing something without scheduler anyway. In case all code is running from ISR the main would then have to look mostly identical to the idle loop:

while (1){
    pm_deepest();
}

I doubt that this would draw more power then using the idle thread instead.

Update: The code calling main could also be written like this:

main();
while(1) {
    pm_deepest();
}

But I'm not sure if it would be better to let the application programmer write the three lines if needed and safe a few bytes if the main does not exit.

Update 2: I think it would be worth the extra bytes flash when keeping one-shot tasks in mind. E.g. examples/hello-world would look better when drawing minimal power after exit and would be a good candidate for dropping multitasking capabilities.

[kaspar030]

The scheduler can already be scaled down easily in terms of RAM usage. E.g., adding these lines to "tests/minimal/Makefile":

CFLAGS += -DMAXTHREADS=2    
CFLAGS += -DSCHED_PRIO_LEVELS=2    

... lowers the RAM usage of the scheduler to 38b (down from 214b with default settings), on samr21-xpro. There is, however, still around 1k code for task switching and thread setup, which wouldn't be needed in a single-thread setup.

Disabling the scheduler and threading altogether is doable by defining "kernel_init()" in the application sources, as e.g., riotboot is doing. That does, on the other hand, currently break a lot of stuff. Don't underestimate how much code assumes that threading is available.

It would definitely be worthwhile to get rid of the idle thread. I think the suggested option of having the (single) main thread to never switch away would again, break too much code that does proper blocking through yielding. E.g., mutex_lock(), event_wait(), thread_sleep(), xtimer_usleep() all work by switching to another context. Others (stdio_uart_read() comes to mind) uses those facilities internally.
The idle thread is actually a quite elegant way of always having somewhere to switch to. Removing this is quite an effort, and unfortunately quite platform dependent.

Once the idle thread is gone, it would be possible to vastly simplify the scheduler for the single-thread case, removing almost all of it's code but retaining the possiblity to suspend the single running thread through the usual ways.

Debunk the "Arduino is better for trival tasks because of resource requirements" argument, which is itching me a lot

The smallest sketch (empty setup(), empty loop()), compiled for arduino zero (a samr21 based one), resulted in this:

[kaspar@ng Arduino]$ arm-none-eabi-size  /tmp/arduino_build_927148/sketch_mar16a.ino.elf                                                     
   text    data     bss     dec     hex filename
  10464     256    2732   13452    348c /tmp/arduino_build_927148/sketch_mar16a.ino.elf                                                      

RIOT's tests/minimal (with this patch) compiles to this:

   text    data     bss     dec     hex filename
   3104      36    2428    5568    15c0 /home/kaspar/src/riot.tmp/tests/minimal/bin/samr21-xpro/tests_minimal.elf

Does that count as "debunking"? 😉

[maribu]

Wow! I was unaware that Arduino one ARM had that overhead. For ARM I would say RIOT won with fanfares and everything 😄

Once the idle thread is gone, it would be possible to vastly simplify the scheduler for the single-thread case, removing almost all of it's code but retaining the possiblity to suspend the single running thread through the usual ways.

I had a similar approach in mind: Providing a sinlge-task version of e.g. thread_sleep(), mutex_lock() etc. If I understood you correctly you would rather keep the layer on top of the scheduler unmodified and provide a stripped down version of the scheduler, while my first through was to provide alternative implementations of the layer on top of the scheduler.

Hmmm, in my tired head both approaches sound to be plausible. Adressing the scheduler would require less modifications once no idle thread is required any more, providing alternative implementations for the layer above would require more separate code, but does not depend.on the idle thread being removed.

[maribu]

Btw: Every post so far was discussing how this (or related ideas) can be done, not if this idea is worthwhile. I'd guess this means it worth giving the idea a try and see if a proof of concept PR can be implemented.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.