| Message ID | 20211104195804.83240-1-posk@google.com (mailing list archive) |
|---|---|
| Headers | show |
| Series | sched,mm,x86/uaccess: implement User Managed Concurrency Groups | expand |
On Fri, Nov 5, 2021 at 8:58 AM Peter Oskolkov <posk@posk.io> wrote: > > User Managed Concurrency Groups (UMCG) is an M:N threading > subsystem/toolkit that lets user space application developers implement > in-process user space schedulers. > > Key changes from the previous patchset > https://lore.kernel.org/all/20211012232522.714898-1-posk@google.com/: > > - added libumcg tools/lib/umcg; > - worker "wakeup" is reworked so that it is now purely a userspace op, > instead of waking the thread in order for it to block on return > to the userspace immediately; > - a couple of minor fixes and refactorings. > > These big things remain to be addressed (in no particular order): > - support tracing/debugging > - make context switches faster (see umcg_do_context_switch in umcg.c) > - support other architectures > - cleanup and post selftests in tools/testing/selftests/umcg/ > - allow cross-mm wakeups (securely) > > > Peter Oskolkov (6): > sched/umcg: add WF_CURRENT_CPU and externise ttwu > mm, x86/uaccess: add userspace atomic helpers > sched/umcg: implement UMCG syscalls > sched/umcg, lib/umcg: implement libumcg > sched/umcg: add Documentation/userspace-api/umcg.txt > sched/umcg, lib/umcg: add tools/lib/umcg/libumcg.txt Hi Peter, Do you have a real workload or an example application using UMCG? > > Documentation/userspace-api/umcg.txt | 598 ++++++++++++ > arch/x86/entry/syscalls/syscall_64.tbl | 2 + > arch/x86/include/asm/uaccess_64.h | 93 ++ > fs/exec.c | 1 + > include/linux/sched.h | 71 ++ > include/linux/syscalls.h | 3 + > include/linux/uaccess.h | 46 + > include/uapi/asm-generic/unistd.h | 6 +- > include/uapi/linux/umcg.h | 137 +++ > init/Kconfig | 10 + > kernel/entry/common.c | 4 +- > kernel/exit.c | 5 + > kernel/sched/Makefile | 1 + > kernel/sched/core.c | 12 +- > kernel/sched/fair.c | 4 + > kernel/sched/sched.h | 15 +- > kernel/sched/umcg.c | 949 +++++++++++++++++++ > kernel/sys_ni.c | 4 + > mm/maccess.c | 264 ++++++ > tools/lib/umcg/.gitignore | 4 + > tools/lib/umcg/Makefile | 11 + > tools/lib/umcg/libumcg.c | 1201 ++++++++++++++++++++++++ > tools/lib/umcg/libumcg.h | 299 ++++++ > tools/lib/umcg/libumcg.txt | 438 +++++++++ > 24 files changed, 4166 insertions(+), 12 deletions(-) > create mode 100644 Documentation/userspace-api/umcg.txt > create mode 100644 include/uapi/linux/umcg.h > create mode 100644 kernel/sched/umcg.c > create mode 100644 tools/lib/umcg/.gitignore > create mode 100644 tools/lib/umcg/Makefile > create mode 100644 tools/lib/umcg/libumcg.c > create mode 100644 tools/lib/umcg/libumcg.h > create mode 100644 tools/lib/umcg/libumcg.txt > > > base-commit: 8ea9183db4ad8afbcb7089a77c23eaf965b0cacd > -- > 2.25.1 > Thanks Barry
Hi Barry, [...] > > Do you have a real workload or an example application using UMCG? > [...] A google-internal variant of UMCG kernel patches is used extensively to enable user-space scheduling of heterogeneous work items. The main use case is services that need to ensure user isolation; in addition, latency vs throughput workloads served by the same service are also well addressed by user-space schedulers. For example, a DBMS needs to ensure that one "hungry" user does not adversely affect other well-behaved users; but at the same time if the overall load is relatively low, users are allowed to go ahead and consume as much CPU as possible, as long as this does not affect other users negatively. Services that treat their work uniformly, and care only about raw throughput, usually do not benefit from custom user-space scheduling that UMCG, or similar, enables. Thanks, Peter