linux-kernel - Re: [PATCH v3 3/7] sched: throttle cfs_rq entities which exceed their local quota

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 14 Oct 2010 12:37:57 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
Cc:	bharata@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	Dhaval Giani <dhaval.giani@...il.com>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>,
	Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Pavel Emelyanov <xemul@...nvz.org>,
	Herbert Poetzl <herbert@...hfloor.at>,
	Avi Kivity <avi@...hat.com>,
	Chris Friesen <cfriesen@...tel.com>,
	Paul Menage <menage@...gle.com>,
	Mike Waychison <mikew@...gle.com>,
	Paul Turner <pjt@...gle.com>, Nikhil Rao <ncrao@...gle.com>
Subject: Re: [PATCH v3 3/7] sched: throttle cfs_rq entities which exceed
 their local quota

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/