Messages in this thread | | | Subject | Re: [ckrm-tech] [PATCH] BC: resource beancounters (v4) (added user memory) | From | Rohit Seth <> | Date | Wed, 13 Sep 2006 18:22:28 -0700 |
| |
On Wed, 2006-09-13 at 15:20 -0700, Chandra Seetharaman wrote: > On Tue, 2006-09-12 at 18:25 -0700, Rohit Seth wrote: > > On Tue, 2006-09-12 at 18:10 -0700, Chandra Seetharaman wrote: > > > On Tue, 2006-09-12 at 17:39 -0700, Rohit Seth wrote: > > > <snip> > > > > > yes, it would be there, but is not heavy, IMO. > > > > > > > > I think anything greater than 1% could be a concern for people who are > > > > not very interested in containers but would be forced to live with them. > > > > > > If they are not interested in resource management and/or containers, i > > > do not think they need to pay. > > > > > > > > Think of a single kernel from a vendor that has container support built > > in. > > Ok. Understood. > > Here are results of some of the benchmarks we have run in the past > (April 2005) with CKRM which showed no/negligible performance impact in > that scenario. > http://marc.theaimsgroup.com/?l=ckrm-tech&m=111325064322305&w=2 > http://marc.theaimsgroup.com/?l=ckrm-tech&m=111385973226267&w=2 > http://marc.theaimsgroup.com/?l=ckrm-tech&m=111291409731929&w=2 > >
These are good results. But I still think the cost will increase over a period of time as more logic gets added. Any data on microbenchmarks like lmbench.
> <snip> > > > > Not at all. If the container they are interested in is guaranteed, I do > > > not see how apps running outside a container would affect them. > > > > > > > Because the kernel (outside the container subsystem) doesn't know of > > The core resource subsystem (VM subsystem for memory) would know about > the guarantees and don't cares, and it would handle it appropriately. >
...meaning hooks in the generic kernel reclaim algorithm. Getting something like that in mainline will be at best tricky.
-rohit
- 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/
| |