Messages in this thread | | | Subject | Re: [RFC][PATCH 00/16] sched: Core scheduling | From | Subhra Mazumdar <> | Date | Wed, 20 Feb 2019 10:43:09 -0800 |
| |
On 2/20/19 1:42 AM, Peter Zijlstra wrote: > A: Because it messes up the order in which people normally read text. > Q: Why is top-posting such a bad thing? > A: Top-posting. > Q: What is the most annoying thing in e-mail? > > On Tue, Feb 19, 2019 at 02:07:01PM -0800, Greg Kerr wrote: >> Thanks for posting this patchset Peter. Based on the patch titled, "sched: A >> quick and dirty cgroup tagging interface," I believe cgroups are used to >> define co-scheduling groups in this implementation. >> >> Chrome OS engineers (kerrnel@google.com, mpdenton@google.com, and >> palmer@google.com) are considering an interface that is usable by unprivileged >> userspace apps. cgroups are a global resource that require privileged access. >> Have you considered an interface that is akin to namespaces? Consider the >> following strawperson API proposal (I understand prctl() is generally >> used for process >> specific actions, so we aren't married to using prctl()): > I don't think we're anywhere near the point where I care about > interfaces with this stuff. > > Interfaces are a trivial but tedious matter once the rest works to > satisfaction. > > As it happens; there is actually a bug in that very cgroup patch that > can cause undesired scheduling. Try spotting and fixing that. > > Another question is if we want to be L1TF complete (and how strict) or > not, and if so, build the missing pieces (for instance we currently > don't kick siblings on IRQ/trap/exception entry -- and yes that's nasty > and horrible code and missing for that reason). I remember asking Paul about this and he mentioned he has a Address Space Isolation proposal to cover this. So it seems this is out of scope of core scheduling? > > So first; does this provide what we need? If that's sorted we can > bike-shed on uapi/abi.
| |