Messages in this thread | | | Date | Fri, 19 Nov 2010 07:55:48 -0500 | From | Mathieu Desnoyers <> | Subject | Re: [RFC/RFT PATCH v3] sched: automated per tty task groups |
| |
* Peter Zijlstra (peterz@infradead.org) wrote: > On Fri, 2010-11-19 at 12:49 +0100, Peter Zijlstra wrote: > > On Fri, 2010-11-19 at 00:43 +0100, Samuel Thibault wrote: > > > What overhead? The implementation of cgroups is actually already > > > hierarchical. > > > > It must be nice to be that ignorant ;-) Speaking for the scheduler > > cgroup controller (that being the only one I actually know), most all > > the load-balance operations are O(n) in the number of active cgroups, > > and a lot of the cpu local schedule operations are O(d) where d is the > > depth of the cgroup tree. > > > > [ and that's with the .38 targeted code, current mainline is O(n ln(n)) > > for load balancing and truly sucks on multi-socket ] > > > > You add a lot of pointer chasing to all the scheduler fast paths and > > there is quite significant data size bloat for even compiling with the > > controller enabled, let alone actually using the stuff. > > > > But sure, treat them as if they were free to use, I guess your machine > > is fast enough. > > In general though, I think you can say that: cgroups ass overhead.
I really think you meant "add" here ? (Hey! The keys were next to each other!) ;)
> Simply because you add constraints, this means you need to 1) account > more, 2) enforce constraints. Both have definite non-zero cost in both > data and time.
Yep, this looks like one of these perpetual throughput vs latency trade-offs.
Thanks,
Mathieu
-- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com
| |