Messages in this thread | | | From | Jonathan Corbet <> | Subject | Re: [RFC PATCH v0.1 0/9] UMCG early preview/RFC patchset | Date | Fri, 21 May 2021 09:08:20 -0600 |
| |
Peter Oskolkov <posk@google.com> writes:
> On Thu, May 20, 2021 at 2:17 PM Jonathan Corbet <corbet@lwn.net> wrote: >> >> Peter Oskolkov <posk@google.com> writes: >> >> > As indicated earlier in the FUTEX_SWAP patchset: >> > >> > https://lore.kernel.org/lkml/20200722234538.166697-1-posk@posk.io/ >> > >> > "Google Fibers" is a userspace scheduling framework >> > used widely and successfully at Google to improve in-process workload >> > isolation and response latencies. We are working on open-sourcing >> > this framework, and UMCG (User-Managed Concurrency Groups) kernel >> > patches are intended as the foundation of this. >> >> So I have to ask...is there *any* documentation out there on what this >> is and how people are supposed to use it? Shockingly, typing "Google >> fibers" into Google leads to a less than fully joyful outcome... This >> won't be easy for anybody to review if they have to start by >> reverse-engineering what it's supposed to do. > > Hi Jonathan, > > There is this Linux Plumbers video: https://www.youtube.com/watch?v=KXuZi9aeGTw > And the pdf: http://pdxplumbers.osuosl.org/2013/ocw//system/presentations/1653/original/LPC%20-%20User%20Threading.pdf > > I did not reference them in the patchset because links to sites other > than kernel.org are strongly discouraged... I will definitely add a > documentation patch.
I did look at those - but a presentation from 2013 is going to be of limited relevance for a 2021 patch set. In particular, the syscall API appears to have evolved considerably since then.
> Feel free to reach out to me directly or through this LKML thread if > you have any questions. > > Do you think a documentation patch would be useful at this point, as > opposed to a free-form email discussion?
Documentation patches can help to guide that discussion; they also need to be reviewed as well. So yes, I think they should be present from the beginning. But then, that's the position I'm supposed to take :) This is a big change to the kernel's system-call API, I don't think that there can be a proper discussion of that without a description of what you're trying to do.
Thanks,
jon
| |