Re: [PATCH v3 3/7] sched: throttle cfs_rq entities which exceedtheir local quota

[Peter Zijlstra]

On Thu, 2010-10-14 at 19:08 +0900, KAMEZAWA Hiroyuki wrote:
> > No, both lead to the same problem, its just that this adds another
> > dimension to it.. and I'm fairly sure people won't realise this until it
> > bites them in the ass.
> > 
> Hmm, them, existing problem but this add a new pitfall.
> 
> What's your recomendation to make progess on this work ?
> 
> I think 1st step will be..
> - explain the problem of priority inversion in cgroup+cfs documenation with
>   !!CAUTION!!
> 
> I'm sorry I'm not sure there have been trials for fixing priority inversion
> in the linux scheduler development.

There's kernel/rtmutex.c which is a mutex implementation with classic PI
that works for SCHED_FIFO/RR.

Thomas and I have been planning of completely rewriting PI support in
the kernel for some time but haven't gotten around to actually doing it.

The goal is to implement a variant of the Proxy Execution Protocol
(close to what gets described here in:
http://www.artist-embedded.org/docs/Events/2010/OSPERT/OSPERT2010-Proceedings.pdf
page 16, Timeslice donation in component based systems).

One of the advantages of PEP is that it works across all scheduling
policies, including proportional fair share schedulers.

It also deals correctly with all PI issues for deadline based schedulers
(correctly handles deadline as well as bandwidth inheritance).

> Explaining my motivation, a user of this feature on my customer is virtual machine
> rental service. So, some fuctionality as
> "When vcpu holds spinlock in kernel, please don't sleep.." will be nice.
> Is there patch already ? 

Well, clearly you cannot sleep while holding a spinlock.. sleeping while
holding a mutex/semaphore is allowed however, but even when you'd have
full PI over all kernel lock (as -rt has), that's not enough, you have
exactly the same problem with all userspace locks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/