Messages in this thread |  | | | Date | Mon, 28 Nov 2011 13:59:29 +0530 | | Subject | Re: [PATCH v2 14/14] Change CPUACCT to default n | | From | Balbir Singh <> |
| |
On Sat, Nov 26, 2011 at 6:48 PM, Paul Turner <pjt@google.com> wrote: > On Fri, Nov 25, 2011 at 2:19 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote: >> On Fri, 2011-11-25 at 11:08 +0530, Balbir Singh wrote: >>> It is not about $customer. I am OK with a design that allows >>> accounting independent of control. Put it another way when I look at >>> cgroups, I see the following functionality >>> >>> 1. Accounting and feedback >>> 2. Control >>> >>> Why do 1 and 2 have to co-exist. A good case would be that we might >>> need just stats and might want to implement control based on 1. >> >> I would say that 2 always requires 1 (provided they are of course on the >> same subject), for the very simple reason that you need to know the >> current state (as provided by 1) to control it (2). >> >> Therefore separating them leads to useless duplication. > > Almost all of the stats that are coming in here are completely useless > for control and don't belong in the cpu controller. > > While it's not as pure we really have 2 tiers of statistic: > > 1) Accounting needed for control > 2) Everything else > > What causes so much over-head for cpuacct currently is that it tries > to maintain a separate accounting of usage. If this were removed from > the controller then it would be *much* cheaper, even with all extra > stats added here. >
Sure, if we can integrate the stats without control, I am all for it :)
Balbir Singh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |