3 ms·
for OOM you do have a lot of flexibility with containers/control groups, nowadays. What kind of problems were they solving with the scheduler? I anything known
by MichaelMoser123 5y ago
for OOM you do have a lot of flexibility with containers/control groups, nowadays. What kind of problems were they solving with the scheduler? I anything known about that?
- dodobirdlord 5y agoFor background context, a reminder that control groups were originally developed in Google’s kernel fork, and later mainlined. As for the scheduler stuff, the main change is a SwitchTo set of syscalls that allow threads to bypass the kernel’s scheduler and just continue execution as a different thread. https://lkml.org/lkml/2020/7/22/1202 https://lkml.org/lkml/2020/7/22/1202
- MichaelMoser123 5y agoThanks for the link, it is explained in the linked video: https://www.youtube.com/watch?v=KXuZi9aeGTw https://www.youtube.com/watch?v=KXuZi9aeGTw They explain it around 15:01 - google added it's own syscall switchto_thread - that puts the current thread to sleep and is switching to the argument thread id. (and some other calls too). That one helps with cutting down latency in inter thread calls for m:n threading. The real effort is to make latency for individual application requests predictable, while keeping it low.
- MichaelMoser123 5y agothe linked video briefly mentions that google has it's own futexs. What would be the difference between regular futexes and the google implementation?
- geofft 5y agoThe article makes a passing reference to "Google Fibers" and "a new API for cooperative scheduling in user space." There seems to be a Phoronix article with some more info and a link to a preparatory patchset that's public: https://www.phoronix.com/scan.php?page=news_item&px=Google-Fibers-Toward-Open https://www.phoronix.com/scan.php?page=news_item&px=Google-F...