|
|
Subscribe / Log in / New account

CFS bandwidth control

By Jonathan Corbet
February 16, 2011
The CFS scheduler does its best to divide the available CPU time between contending processes, keeping the CPU utilization of each about the same. The scheduler will not, however, insist on equal utilization when there is free CPU time available; rather than let the CPU go idle, the scheduler will give any left-over time to processes which can make use of it. This approach makes sense; there is little point in throttling runnable processes when nobody else wants the CPU anyway.

Except that, sometimes, that's exactly what a system administrator may want to do. Limiting the maximum share of CPU time that a process (or group of processes) may consume can be desirable if those processes belong to a customer who has only paid for a certain amount of CPU time or in situations where it is necessary to provide strict resource-use isolation between processes. The CFS scheduler cannot limit CPU use in that manner, but the CFS bandwidth control patches, posted by Paul Turner, may change that situation.

This patch adds a couple of new control files to the CPU control group mechanism: cpu.cfs_period_us defines the period over which the group's CPU usage is to be regulated, and cpu.cfs_quota_us controls how much CPU time is available to the group over that period. With these two knobs, the administrator can easily limit a group to a certain amount of CPU time and also control the granularity with which that limit is enforced.

Paul's patch is not the only one aimed at solving this problem; the CFS hard limits patch set from Bharata B Rao provides nearly identical functionality. The implementation is different, though; the hard limits patch tries to reuse some of the bandwidth-limiting code from the realtime scheduler to impose the limits. Paul has expressed concerns about the overhead of using this code and how well it will work in situations where the CPU is almost fully subscribed. These concerns appear to have carried the day - there has not been a hard limits patch posted since early 2010. So the CFS bandwidth control patches look like the form this functionality will take in the mainline.

Index entries for this article
KernelGroup scheduling
KernelScheduler/Completely fair scheduler


to post comments

CFS bandwidth control

Posted Feb 17, 2011 8:51 UTC (Thu) by mhelsley (guest, #11324) [Link] (2 responses)

"These concerns appear to have carried the day - there has not been a hard limits patch posted since early 2010."

I don't follow your reasoning since as far as I can tell there have been later postings than "early 2010":

https://lkml.org/lkml/2010/10/12/44

CFS bandwidth control

Posted Feb 17, 2011 13:53 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

The posting you link to says:

"Paul's approach mainly changed the way the CPU hard limit was represented. After his post, I decided to work with them and discontinue my patch series since their global bandwidth specification for group appears more flexible than the RT-type per-cpu bandwidth specification I had in my series."

In other words, Bharata posted a version of the bandwidth control patch - not the hard limits patch which, I still believe, has not seen a revision since January of last year.

CFS bandwidth control

Posted Feb 22, 2011 5:21 UTC (Tue) by bharata (subscriber, #7885) [Link]

Yes, As I said in the v3 post of CFS bandwidth control patches, I am putting my efforts behind Paul's patches and avoiding duplication.


Copyright © 2011, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds