[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1315423342.11101.25.camel@twins>
Date: Wed, 07 Sep 2011 21:22:22 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Cc: Paul Turner <pjt@...gle.com>,
Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
Vladimir Davydov <vdavydov@...allels.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
Bharata B Rao <bharata@...ux.vnet.ibm.com>,
Dhaval Giani <dhaval.giani@...il.com>,
Vaidyanathan Srinivasan <svaidy@...ux.vnet.ibm.com>,
Ingo Molnar <mingo@...e.hu>,
Pavel Emelianov <xemul@...allels.com>
Subject: Re: CFS Bandwidth Control - Test results of cgroups tasks pinned vs
unpinnede
On Wed, 2011-09-07 at 20:50 +0530, Srivatsa Vaddagiri wrote:
>
> Fix excessive idle time reported when cgroups are capped.
Where from? The whole idea of bandwidth caps is to introduce idle time,
so what's excessive and where does it come from?
> The patch introduces the notion of "steal"
The virt folks already claimed steal-time and have it mean something
entirely different. You get to pick a new name.
> (or "grace") time which is the surplus
> time/bandwidth each cgroup is allowed to consume, subject to a maximum
> steal time (sched_cfs_max_steal_time_us). Cgroups are allowed this "steal"
> or "grace" time when the lone task running on a cpu is about to be throttled.
Ok, so this is a solution to an unstated problem. Why is it a good
solution?
Also, another tunable, yay!
--
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/
Powered by blists - more mailing lists