3 ms·

That's certainly a more complex interface, but I don't think it enables anything more. I think switchto (which became futex_swap which became umcg_swap) from t

That's certainly a more complex interface, but I don't think it enables anything more. I think switchto (which became futex_swap which became umcg_swap) from thread X is roughly "suspend the current thread (X) and unsuspend Y", where suspend is "wait on a futex". When all of the tasks you propose specifying are done, one of them can just unsuspend X (possibly suspending itself at the same time). (Caveat: I don't really know what changed between futex_swap and umcg_swap.) btw, I don't think it's fair to say the kernel maintainers lacked the industry experience to perceive the benefits. I've glanced at some of the UMCG threads and it seems like reviewers have legitimate feedback aimed at improving the patchset rather than rejecting it. Assuming posk has enough time to keep making new drafts, I expect it to be merged eventually.

marcodiego 5y ago
Note: I'm far from an expert and I'm purely speculating here hoping for educated commenters to show me why I'm wrong. The described approach allow, for example, for a process to choose how its children will be scheduled. I don't think google's proposal allows that.
- scottlamb 5y ago
  Yes, I think you're right that UMCG is just for within a single process. It's meant to support Google's fibers library, which offers a nice structured concurrency programming model within a process with nested schedulers. Eg, the outermost scheduler might be earliest fiber tree gets scheduled first, and then within a fiber tree (which often represents one request) the scheduler is typically LIFO for efficiency. The idea is that when using this library, the process has more information about what its threads are doing, so it can make better scheduling decisions than the kernel and can do it more quickly. It doesn't replace the kernel scheduler exactly, just makes it have less to do because there are fewer unblocked threads per process. This ghOSt thing looks unrelated and system-wide. Like a more customizable version of the usual kernel scheduling. But I'm guessing based on one paragraph and will be interested to see the paper/presentation. I'm not sure if there's any big gap between where neither does what you want.
jeffbee 5y ago
Eh, I take a dim view of the largely superficial reactions this patch set has garnered. The maintainers think their aesthetic concerns are more important than the Linux-using public getting access to this api. It doesn’t seem to me like years of debate have improved it, just delayed it.

marcodiego 5y ago

Note: I'm far from an expert and I'm purely speculating here hoping for educated commenters to show me why I'm wrong. The described approach allow, for example, for a process to choose how its children will be scheduled. I don't think google's proposal allows that.

scottlamb 5y ago
Yes, I think you're right that UMCG is just for within a single process. It's meant to support Google's fibers library, which offers a nice structured concurrency programming model within a process with nested schedulers. Eg, the outermost scheduler might be earliest fiber tree gets scheduled first, and then within a fiber tree (which often represents one request) the scheduler is typically LIFO for efficiency. The idea is that when using this library, the process has more information about what its threads are doing, so it can make better scheduling decisions than the kernel and can do it more quickly. It doesn't replace the kernel scheduler exactly, just makes it have less to do because there are fewer unblocked threads per process. This ghOSt thing looks unrelated and system-wide. Like a more customizable version of the usual kernel scheduling. But I'm guessing based on one paragraph and will be interested to see the paper/presentation. I'm not sure if there's any big gap between where neither does what you want.

jeffbee 5y ago

Eh, I take a dim view of the largely superficial reactions this patch set has garnered. The maintainers think their aesthetic concerns are more important than the Linux-using public getting access to this api. It doesn’t seem to me like years of debate have improved it, just delayed it.