Thomas Gleixner <t...@linutronix.de> writes: > On Tue, 4 Mar 2014, Khalid Aziz wrote: >> be in the right control group. Besides they want to use a common mechanism >> across multiple OSs and pre-emption delay is already in use on other OSs. >> Good >> idea though. > > Well, just because preemption delay is a mechanism exposed by some > other OS does not make it a good idea. > > In fact its a horrible idea. > > What you are creating is a crystal ball based form of time bound > priority ceiling with the worst user space interface i've ever seen.
So how would you solve the user space lock holder preemption problem then? It's a real problem, affecting lots of workloads. Just saying everything is crap without suggesting anything constructive is not really getting us anywhere. The workarounds I've seen for it are generally far worse than this. Often people do all kinds of fragile tunings to address this, when then break on the next kernel update that does even a minor scheduler change. futex doesn't solve the problem at all. The real time scheduler is also really poor fit for these workloads and needs a lot of hacks to scale. The thread swap proposal from plumbers had some potential, but it's likely very intrusive everywhere and seems to have died too. Anything else? -Andi -- a...@linux.intel.com -- Speaking for myself only -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/