> From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Thursday, 26 October 2023 21.51 > > 26/10/2023 18:50, Morten Brørup: > > > From: Thomas Monjalon [mailto:tho...@monjalon.net] > > > Sent: Thursday, 26 October 2023 18.07
[...] > > > For average realtime thread, I suggest the API > > > rte_thread_yield_realtime() > > > which could wait for 1 ms or less by default. > > > > If we introduce a yield() function, it should yield according to the > O/S scheduling policy, e.g. the rest of the time slice allocated to the > thread by the O/S scheduler (although that might not be available for > real-time prioritized threads in Linux). I don't think we can make it > O/S agnostic. > > > > I don't think it should wait a fixed amount of time - we already have > rte_delay_us_sleep() for that. > > > > In my experiments with power saving, I ended up with a varying sleep > duration, depending on traffic load. The l3fwd-power example also uses > a varying sleep duration depending on traffic load. > > I feel you lost the goal of this: schedule other threads (especially > kernel threads). > So we don't care about the sleep duration at all, > except we want it minimal while allowing scheduling. I do understand the goal: We want to relinquish the CPU core briefly, so the RT-priority thread gives way for other threads to run on the same CPU core. But I don't think it is possible for an RT-priority thread to yield without waiting in a blocking call or waiting for an explicit timeout. This is the reason why Stephen wants the big fat warning sign when assigning RT-priority to a thread. This will happen if we don't provide something for the RT-priority thread to wait for: The application thread calls "yield()", e.g. sleep(0), to pass control to the kernel scheduler. The kernel scheduler looks at all tasks available. The application thread has RT-priority and is ready to run, so the kernel scheduler will pick this thread for running. Only if other RT-priority threads are ready to run, perhaps one of those will be picked. No other threads will be picked, not even kernel threads (because RT-priority is higher than the priority of the kernel threads). [...] > Windows should be fine with Sleep(0). Reading the Win32 API documentation [1] carefully, it think it will generally behave like the Linux scheduler. It says: "A value of zero causes the thread to relinquish the remainder of its time slice to any other thread of equal priority that is ready to run. If there are no other threads of equal priority ready to run, the function returns immediately, and the thread continues execution. This behavior changed starting with Windows Server 2003." How I interpret this is: The Windows scheduler will not relinquish the CPU core to lower priority threads when calling Sleep(0). If the application thread has RT-priority, the scheduler will immediately pick the same thread. Only if other RT-priority threads are ready to run, one of those will be picked. [1]: https://learn.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-sleep
