On Wed, 4 Mar 2015, Luke Kenneth Casson Leighton wrote:
and why he concludes that having a single hierarchy for all resource types.
correcting to add "is not always a good idea"
i think having a single hierarchy is fine *if* and only if it is
possible to overlay something similar to S
On Wed, Mar 4, 2015 at 5:08 AM, David Lang wrote:
> On Tue, 3 Mar 2015, Luke Leighton wrote:
>> whilst the majority of people view management to be "hierarchical"
>> (so there is a top dog or God process and everything trickles down
>> from that), this is viewed as such an anathema in the securi
On Tue, 3 Mar 2015, Luke Leighton wrote:
I wrote about that many times, but here are two of the problems.
* There's no way to designate a cgroup to a resource, because cgroup
is only defined by the combination of who's looking at it for which
controller. That's how you end up with tagging
Serge Hallyn writes:
>
> Quoting Daniel P. Berrange (berrange@...):
> > Are you also planning to actually write a new cgroup parent manager
> > daemon too ? Currently my plan for libvirt is to just talk directly
>
> I'm toying with the idea, yes. (Right now my toy runs in either native
> mode
Tejun Heo writes:
>
> Hello, Serge.
>
> On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
> > At some point (probably soon) we might want to talk about a standard API
> > for these things. However I think it will have to come in the form of
> > a standard library, which knows to ei
Serge Hallyn writes:
>
> Quoting Tim Hockin (thockin@...):
> > > FWIW, the code is too embarassing yet to see daylight, but I'm playing
> > > with a very lowlevel cgroup manager which supports nesting itself.
> > > Access in this POC is low-level ("set freezer.state to THAWED for cgroup
> > > /
Tejun Heo writes:
>
> Hello, Tim.
>
> On Fri, Jun 28, 2013 at 11:44:23AM -0700, Tim Hockin wrote:
> The goal is to reach sane and widely useable / useful state with
> minimum amount of complexity. Maintaining backward compatibility for
> some period - likely quite a few years - while still a
Tejun Heo writes:
>
> Hello, Tim.
>
> On Wed, Jun 26, 2013 at 08:42:21PM -0700, Tim Hockin wrote:
> > OK, then what I don't know is what is the new interface? A new cgroupfs?
>
> It's gonna be a new mount option for cgroupfs.
>
> > DTF and CPU and cpuset all have "default" groups for some ta
Tejun Heo writes:
> I don't really understand your example anyway because you can classify
> by DTF / non-DTF first and then just propagate cpuset settings along.
> You won't lose anything that way, right?
without spoiling the fun by reading ahead, based on the extreme
complexity of what tim'
On Mon 15-07-13 14:49:40, Vivek Goyal wrote:
> On Sun, Jun 30, 2013 at 08:38:38PM +0200, Michal Hocko wrote:
> > On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> > > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> > [...]
> > > > OK, so libcgroup's rules daemon will still work and pla
On Sun, Jun 30, 2013 at 08:38:38PM +0200, Michal Hocko wrote:
> On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> [...]
> > > OK, so libcgroup's rules daemon will still work and place my tasks in
> > > appropriate cgroups?
> >
> > Do y
On Wed, 3 Jul 2013, Kay Sievers wrote:
> >> > But that's not my point. It seems pretty easy to make this cgroup
> >> > management (in "native mode") a library that can have either a thin
> >> > veneer of a main() function, while also being usable by systemd. The
> >> > point is to solve all of t
On Wed, 2013-07-03 at 01:57 +0200, Thomas Gleixner wrote:
> Lennart,
>
> On Sun, 30 Jun 2013, Lennart Poettering wrote:
> > On 29.06.2013 05:05, Tim Hockin wrote:
> > > But that's not my point. It seems pretty easy to make this cgroup
> > > management (in "native mode") a library that can have ei
On Wed, 3 Jul 2013, Kay Sievers wrote:
> On Wed, Jul 3, 2013 at 1:57 AM, Thomas Gleixner wrote:
> > Before answering please think about the relevance of your statements
> > "getting this all right isn't easy", "something like a scheduler",
> > "users probably want ..." and "stable /dev/disk/by-id
On Wed, Jul 03, 2013 at 02:44:31AM +0200, Kay Sievers wrote:
> I don't think anybody needs your money.
>
> But it's sure an improvement over last time when you wanted to use a
> "Kantholz" to make your statement.
Kantholz, frozen sharks, whatever helps get the real point across. Hint:
this is not
On Wed, Jul 3, 2013 at 1:57 AM, Thomas Gleixner wrote:
> On Sun, 30 Jun 2013, Lennart Poettering wrote:
>> On 29.06.2013 05:05, Tim Hockin wrote:
>> > But that's not my point. It seems pretty easy to make this cgroup
>> > management (in "native mode") a library that can have either a thin
>> > ve
Lennart,
On Sun, 30 Jun 2013, Lennart Poettering wrote:
> On 29.06.2013 05:05, Tim Hockin wrote:
> > But that's not my point. It seems pretty easy to make this cgroup
> > management (in "native mode") a library that can have either a thin
> > veneer of a main() function, while also being usable b
On Sun, Jun 30, 2013 at 12:39 PM, Lennart Poettering
wrote:
> Heya,
>
>
> On 29.06.2013 05:05, Tim Hockin wrote:
>>
>> Come on, now, Lennart. You put a lot of words in my mouth.
>
>
>>> I for sure am not going to make the PID 1 a client of another daemon.
>>> That's
>>> just wrong. If you have a
Heya,
On 29.06.2013 05:05, Tim Hockin wrote:
Come on, now, Lennart. You put a lot of words in my mouth.
I for sure am not going to make the PID 1 a client of another daemon. That's
just wrong. If you have a daemon that is both conceptually the manager of
another service and the client of tha
On Fri 28-06-13 14:01:55, Vivek Goyal wrote:
> On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
[...]
> > OK, so libcgroup's rules daemon will still work and place my tasks in
> > appropriate cgroups?
>
> Do you use that daemon in practice?
I am not but my users do. And that is why I
Hello, Tim.
On Fri, Jun 28, 2013 at 11:44:23AM -0700, Tim Hockin wrote:
> I totally understand where you're coming from - trying to get back to
> a stable feature set. But it sucks to be on the losing end of that
Oh, it has been sucking and will continue to suck like hell for me too
for the fore
Come on, now, Lennart. You put a lot of words in my mouth.
On Fri, Jun 28, 2013 at 6:48 PM, Lennart Poettering wrote:
> On 28.06.2013 20:53, Tim Hockin wrote:
>
>> a single-agent, we should make a kick-ass implementation that is
>> flexible and scalable, and full-featured enough to not require
>
On 28.06.2013 20:53, Tim Hockin wrote:
a single-agent, we should make a kick-ass implementation that is
flexible and scalable, and full-featured enough to not require
divergence at the lowest layer of the stack. Then build systemd on
top of that. Let systemd offer more features and policies and
On Fri, Jun 28, 2013 at 05:40:53PM -0500, Serge Hallyn wrote:
> > The kernel can exposed a knob that would allow systemd to lock that
> > down
>
> Gah - why would you give him that idea? :)
That's one of the ideas I had from the beginning.
> But yes, I'd sort of assume that was coming, eventual
Quoting Daniel P. Berrange (berra...@redhat.com):
> On Fri, Jun 28, 2013 at 02:01:55PM -0400, Vivek Goyal wrote:
> > On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> > > On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> > > > Hello, Mike.
> > > >
> > > > On Fri, Jun 28, 2013 at 06:49:10A
On Fri, Jun 28, 2013 at 02:01:55PM -0400, Vivek Goyal wrote:
> On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> > On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> > > Hello, Mike.
> > >
> > > On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> > > > I always thought that w
Quoting Andy Lutomirski (l...@amacapital.net):
> On 06/27/2013 11:01 AM, Tejun Heo wrote:
> > AFAICS, having a userland agent which has overall knowledge of the
> > hierarchy and enforcesf structure and limiations is a requirement to
> > make cgroup generally useable and useful. For systemd based
On 06/27/2013 11:01 AM, Tejun Heo wrote:
> AFAICS, having a userland agent which has overall knowledge of the
> hierarchy and enforcesf structure and limiations is a requirement to
> make cgroup generally useable and useful. For systemd based systems,
> systemd serving that role isn't too crazy.
On Fri, Jun 28, 2013 at 8:53 AM, Serge Hallyn wrote:
> Quoting Daniel P. Berrange (berra...@redhat.com):
>> Are you also planning to actually write a new cgroup parent manager
>> daemon too ? Currently my plan for libvirt is to just talk directly
>
> I'm toying with the idea, yes. (Right now my
On Fri, Jun 28, 2013 at 8:05 AM, Michal Hocko wrote:
> On Thu 27-06-13 22:01:38, Tejun Heo wrote:
>> Oh, that in itself is not bad. I mean, if you're root, it's pretty
>> easy to play with and that part is fine. But combined with the
>> hierarchical nature of cgroup and file permissions, it enc
On Thu, Jun 27, 2013 at 2:04 PM, Tejun Heo wrote:
> Hello,
>
> On Thu, Jun 27, 2013 at 01:46:18PM -0700, Tim Hockin wrote:
>> So what you're saying is that you don't care that this new thing is
>> less capable than the old thing, despite it having real impact.
>
> Sort of. I'm saying, at least up
Hello, Michal.
On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> OK, this really depends on what you expose to non-root users. I have
> seen use cases where admin prepares top-level which is root-only but
> it allows creating sub-groups which are under _full_ control of the
> subdoma
On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> > Hello, Mike.
> >
> > On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> > > I always thought that was a very cool feature, mkdir+echo, poof done.
> > > Now maybe that inter
Quoting Daniel P. Berrange (berra...@redhat.com):
> On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
> > FWIW, the code is too embarassing yet to see daylight, but I'm playing
> > with a very lowlevel cgroup manager which supports nesting itself.
> > Access in this POC is low-level ("s
On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> Hello, Mike.
>
> On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> > I always thought that was a very cool feature, mkdir+echo, poof done.
> > Now maybe that interface is suboptimal for serious usage, but it makes
> > the things usable v
On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
> FWIW, the code is too embarassing yet to see daylight, but I'm playing
> with a very lowlevel cgroup manager which supports nesting itself.
> Access in this POC is low-level ("set freezer.state to THAWED for cgroup
> /c1/c2", "Create /
On Thu, 2013-06-27 at 22:01 -0700, Tejun Heo wrote:
> Anyways, if you're root, you can keep doing whatever you want. You
> could be stepping on the centralized agent's toes a bit and vice-versa
Keep on truckn' sounds good, that vice-versa toe stomping not so good,
but yeah, until systemd or ilk
Hello, Mike.
On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> I always thought that was a very cool feature, mkdir+echo, poof done.
> Now maybe that interface is suboptimal for serious usage, but it makes
> the things usable via dirt simple scripts, very flexible, nice.
Oh, that
On Thu, 2013-06-27 at 21:09 -0700, Tejun Heo wrote:
> No, it's completely messed up. We're now starting to see users trying
> to embed low level cgroup details into their binaries and cgroup is
> exposing sysctl-level konbs which are directly tied to internal
> implementation of core subsystems.
Hello, Mike.
On Fri, Jun 28, 2013 at 05:46:38AM +0200, Mike Galbraith wrote:
> Sure, because in private property and I mandatory agent, I see "gimme
> yer wallet bitch", an incredibly arrogant and brutal mugging. That's
> not the way it's meant, I know that, but that's how it comes across.
> You
On Thu, 2013-06-27 at 11:01 -0700, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, Jun 27, 2013 at 07:45:07AM +0200, Mike Galbraith wrote:
> > I can understand some alarm. When I saw the below I started frothing at
> > the face and howling at the moon, and I don't even use the things much.
>
> Can
Hello,
On Thu, Jun 27, 2013 at 01:46:18PM -0700, Tim Hockin wrote:
> So what you're saying is that you don't care that this new thing is
> less capable than the old thing, despite it having real impact.
Sort of. I'm saying, at least up until now, moving away from
orthogonal hierarchy support see
On Thu, Jun 27, 2013 at 11:14 AM, Serge Hallyn wrote:
> Quoting Tejun Heo (t...@kernel.org):
>> Hello, Serge.
>>
>> On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
>> > At some point (probably soon) we might want to talk about a standard API
>> > for these things. However I think it
On Thu, Jun 27, 2013 at 10:38 AM, Tejun Heo wrote:
> Hello, Tim.
>
> On Wed, Jun 26, 2013 at 08:42:21PM -0700, Tim Hockin wrote:
>> OK, then what I don't know is what is the new interface? A new cgroupfs?
>
> It's gonna be a new mount option for cgroupfs.
>
>> DTF and CPU and cpuset all have "def
Hello,
On Thu, Jun 27, 2013 at 11:51 AM, Serge Hallyn wrote:
>> I think it probably would be better to allow organization and RO
>
> What do you mean by "organization"? Creating cgroups and moving tasks
> between them, without setting other cgroup values?
Yeap, I also think that's how user sess
Quoting Tejun Heo (t...@kernel.org):
> Hello, Serge.
>
> On Thu, Jun 27, 2013 at 01:14:57PM -0500, Serge Hallyn wrote:
> > I should find a good, up-to-date summary of the current behaviors of
> > each controller so I can talk more intelligently about it. (I'll
> > start by looking at the kernel D
Hello, Serge.
On Thu, Jun 27, 2013 at 01:14:57PM -0500, Serge Hallyn wrote:
> I should find a good, up-to-date summary of the current behaviors of
> each controller so I can talk more intelligently about it. (I'll
> start by looking at the kernel Documentation/cgroups, but don't
> feel too confid
Quoting Tejun Heo (t...@kernel.org):
> Hello, Serge.
>
> On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
> > At some point (probably soon) we might want to talk about a standard API
> > for these things. However I think it will have to come in the form of
> > a standard library, whi
Hello, Mike.
On Thu, Jun 27, 2013 at 07:45:07AM +0200, Mike Galbraith wrote:
> I can understand some alarm. When I saw the below I started frothing at
> the face and howling at the moon, and I don't even use the things much.
Can I ask why? The reasons are not apparent to me.
> http://lists.fre
Hello, Serge.
On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
> At some point (probably soon) we might want to talk about a standard API
> for these things. However I think it will have to come in the form of
> a standard library, which knows to either send requests over dbus to
> s
Hello, Tim.
On Wed, Jun 26, 2013 at 08:42:21PM -0700, Tim Hockin wrote:
> OK, then what I don't know is what is the new interface? A new cgroupfs?
It's gonna be a new mount option for cgroupfs.
> DTF and CPU and cpuset all have "default" groups for some tasks (and
> not others) in our world tod
Quoting Tim Hockin (thoc...@hockin.org):
> On Thu, Jun 27, 2013 at 6:22 AM, Serge Hallyn wrote:
> > Quoting Mike Galbraith (bitbuc...@online.de):
> >> On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote:
> >> > Hello, Tim.
> >> >
> >> > On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
>
On Thu, Jun 27, 2013 at 6:22 AM, Serge Hallyn wrote:
> Quoting Mike Galbraith (bitbuc...@online.de):
>> On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote:
>> > Hello, Tim.
>> >
>> > On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
>> > > I really want to understand why this is SO IMPOR
Quoting Mike Galbraith (bitbuc...@online.de):
> On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote:
> > Hello, Tim.
> >
> > On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
> > > I really want to understand why this is SO IMPORTANT that you have to
> > > break userspace compatibility?
On Wed, 2013-06-26 at 14:20 -0700, Tejun Heo wrote:
> Hello, Tim.
>
> On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
> > I really want to understand why this is SO IMPORTANT that you have to
> > break userspace compatibility? I mean, isn't Linux supposed to be the
> > OS with the st
On Wed, Jun 26, 2013 at 6:04 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 26, 2013 at 05:06:02PM -0700, Tim Hockin wrote:
>> The first assertion, as I understood, was that (eventually) cgroupfs
>> will not allow split hierarchies - that unified hierarchy would be the
>> only mode. Is that not th
Hello,
On Wed, Jun 26, 2013 at 05:06:02PM -0700, Tim Hockin wrote:
> The first assertion, as I understood, was that (eventually) cgroupfs
> will not allow split hierarchies - that unified hierarchy would be the
> only mode. Is that not the case?
No, unified hierarchy would be an optional thing f
On Wed, 26 Jun 2013, Tim Hockin wrote:
On Wed, Jun 26, 2013 at 2:20 PM, Tejun Heo wrote:
Hello, Tim.
On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
I really want to understand why this is SO IMPORTANT that you have to
break userspace compatibility? I mean, isn't Linux supposed
On Wed, Jun 26, 2013 at 2:20 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
>> I really want to understand why this is SO IMPORTANT that you have to
>> break userspace compatibility? I mean, isn't Linux supposed to be the
>> OS with the stable k
Hello, Tim.
On Mon, Jun 24, 2013 at 09:07:47PM -0700, Tim Hockin wrote:
> I really want to understand why this is SO IMPORTANT that you have to
> break userspace compatibility? I mean, isn't Linux supposed to be the
> OS with the stable kernel interface? I've seen Linus rant time and
> time agai
On Mon, Jun 24, 2013 at 5:01 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Sat, Jun 22, 2013 at 04:13:41PM -0700, Tim Hockin wrote:
>> I'm very sorry I let this fall off my plate. I was pointed at a
>> systemd-devel message indicating that this is done. Is it so? It
>
> It's progressing pretty fast
Hello, Tim.
On Sat, Jun 22, 2013 at 04:13:41PM -0700, Tim Hockin wrote:
> I'm very sorry I let this fall off my plate. I was pointed at a
> systemd-devel message indicating that this is done. Is it so? It
It's progressing pretty fast.
> seems so completely ass-backwards to me. Below is one of
I'm very sorry I let this fall off my plate. I was pointed at a
systemd-devel message indicating that this is done. Is it so? It
seems so completely ass-backwards to me. Below is one of our use-cases
that I just don't see how we can reproduce in a single-heierarchy.
We're also long into the mode
On Mon, Apr 22, 2013 at 11:41 PM, Tejun Heo wrote:
> Hello, Tim.
>
> On Mon, Apr 22, 2013 at 11:26:48PM +0200, Tim Hockin wrote:
>> We absolutely depend on the ability to split cgroup hierarchies. It
>> pretty much saved our fleet from imploding, in a way that a unified
>> hierarchy just could no
Hello, Tim.
On Mon, Apr 22, 2013 at 11:26:48PM +0200, Tim Hockin wrote:
> We absolutely depend on the ability to split cgroup hierarchies. It
> pretty much saved our fleet from imploding, in a way that a unified
> hierarchy just could not do. A mandated unified hierarchy is madness.
> Please st
Hi Tejun,
This email worries me. A lot. It sounds very much like retrograde
motion from our (Google's) point of view.
We absolutely depend on the ability to split cgroup hierarchies. It
pretty much saved our fleet from imploding, in a way that a unified
hierarchy just could not do. A mandated
On 2013/4/17 1:10, Tejun Heo wrote:
> Hello, Li.
>
> On Tue, Apr 16, 2013 at 07:17:17PM +0800, Li Zefan wrote:
> ...
>>> hot-unplug). It currently transfers all its tasks to the nearest
>>> ancestor with executing resources, which is an irreversible process
>>> which would affect all other co-mou
Hello, Li.
On Tue, Apr 16, 2013 at 07:17:17PM +0800, Li Zefan wrote:
...
> > hot-unplug). It currently transfers all its tasks to the nearest
> > ancestor with executing resources, which is an irreversible process
> > which would affect all other co-mounted controllers. We probably want
> > it t
On 2013/4/6 9:21, Tejun Heo wrote:
> Hello, guys.
>
> Status-quo
> ==
>
> It's been about a year since I wrote up a summary on cgroup status quo
> and future plans. We're not there yet but much closer than we were
> before. At least the locking and object life-time management aren't
>
Hey, Serge.
On Tue, Apr 09, 2013 at 04:04:22PM -0500, Serge Hallyn wrote:
> So for instance if there is a dbus call saying "please create cgroup
> /x with (some constraints) and put $$ into it", "something" in the
> container can convert that into "please create cgroup /lxc/c1/x
> and put (host_ui
Quoting Tejun Heo (t...@kernel.org):
> A bit of addition.
>
> On Tue, Apr 09, 2013 at 12:38:51PM -0700, Tejun Heo wrote:
> > > We need to make the distribute approach work in order to support
> > > containers, which requiring them to have a back-channel open to
> > > the host userspace. If we can
A bit of addition.
On Tue, Apr 09, 2013 at 12:38:51PM -0700, Tejun Heo wrote:
> > We need to make the distribute approach work in order to support
> > containers, which requiring them to have a back-channel open to
> > the host userspace. If we can do that, then we've solved the problem
Why is ba
Hello, Daniel.
On Tue, Apr 09, 2013 at 10:50:25AM +0100, Daniel P. Berrange wrote:
> The PaxControlGroups document is the key piece to making distributed
> management work. This document does need updating, since some of what
> it describes doesn't really work, but its goal is sound IMHO.
I think
Hello,
On Tue, Apr 09, 2013 at 01:32:01AM +0200, Lennart Poettering wrote:
> The other big thing we want from the systemd side is saner
> notifications when cgroups run empty. i.e. currently we don't get
> these at all in containers (since the agent can be only installed
> once, for the host). And
On Fri, Apr 05, 2013 at 06:21:59PM -0700, Tejun Heo wrote:
> Userland efforts
>
>
> There are currently a few userland efforts trying to make interfacing
> with cgroup less painful.
>
> * libcg: Make cgroup interface accessible from programming languages
> with support for co
On 04/09/2013 03:32 AM, Lennart Poettering wrote:
> The other big thing we want from the systemd side is saner notifications
> when cgroups run empty. i.e. currently we don't get these at all in
> containers (since the agent can be only installed once, for the host).
> And the way we get this is aw
Heya,
On 08.04.2013 15:46, Glauber Costa wrote:
On 04/06/2013 05:21 AM, Tejun Heo wrote:
Hello, guys.
Hello Tejun, how are you?
Status-quo
==
tl;did read;
This is mostly sensible. There is still one problem that we hadn't yet
had the bandwidth to tackle that should be added t
On Mon, Apr 08, 2013 at 03:46:31PM -0400, Vivek Goyal wrote:
> It would be good to think more about it. How a user can ensure minimum
> resources to a partition/service. Because in that case at every level
> somebody needs to keep track how much of resources have been committed
> as minimum require
On Mon, Apr 08, 2013 at 12:20:24PM -0700, Tejun Heo wrote:
[..]
> > For example, one might want to say that maximum IO bandwidth for
> > virtual machine virt1 on disk sda should be 10MB/s. Now libvirt
> > should be able to save it in virtual machine specific configuration
> > easily and whenever
Hey,
On Mon, Apr 08, 2013 at 03:11:05PM -0400, Vivek Goyal wrote:
> > What if the program crashes?
>
> I am not sure about this. I guess when applications comes back after crash,
> it can go through all the children cgroups and reclaim empty cgroups.
Fragile, right? What are you arguing here?
On Mon, Apr 08, 2013 at 11:16:07AM -0700, Tejun Heo wrote:
> Hey, Vivek.
>
> On Mon, Apr 08, 2013 at 01:59:26PM -0400, Vivek Goyal wrote:
> > But using the library admin application should be able to query the
> > full "paritition" hierarchy and their weigths and calculate % system
> > resources.
On Mon, Apr 08, 2013 at 11:16:07AM -0700, Tejun Heo wrote:
> > Given the fact that library has view of full system resoruces (both
> > persistent view and active view), shouldn't we just be able to extend
> > the API to meet additional configuration or resource needs.
>
> Maybe, I don't know. It
Hey, Glauber.
On Mon, Apr 08, 2013 at 05:46:09PM +0400, Glauber Costa wrote:
> On 04/06/2013 05:21 AM, Tejun Heo wrote:
> > Hello, guys.
>
> Hello Tejun, how are you?
I'm doing okay. :)
> > Status-quo
> > ==
> >
> tl;did read;
>
> This is mostly sensible. There is still one problem
Hey, Vivek.
On Mon, Apr 08, 2013 at 01:59:26PM -0400, Vivek Goyal wrote:
> But using the library admin application should be able to query the
> full "paritition" hierarchy and their weigths and calculate % system
> resources. I think one problem there is cpu controller where % resoruce
> of a cgr
On Mon, Apr 08, 2013 at 05:46:09PM +0400, Glauber Costa wrote:
[..]
> The cpu cgroup needs a real-time timeslice to accept real time tasks. It
> defaults to 0, meaning that a newly created cpu cgroup cannot accept
> tasks (rt tasks) without the user having to manually configure it.
> As far as I k
On Fri, Apr 05, 2013 at 06:21:59PM -0700, Tejun Heo wrote:
[..]
> Userland efforts
>
>
> There are currently a few userland efforts trying to make interfacing
> with cgroup less painful.
>
> * libcg: Make cgroup interface accessible from programming languages
> with support
On 04/06/2013 05:21 AM, Tejun Heo wrote:
> Hello, guys.
>
Hello Tejun, how are you?
> Status-quo
> ==
>
tl;did read;
This is mostly sensible. There is still one problem that we hadn't yet
had the bandwidth to tackle that should be added to your official TODO list.
The cpu cgroup need
Hello, guys.
Status-quo
==
It's been about a year since I wrote up a summary on cgroup status quo
and future plans. We're not there yet but much closer than we were
before. At least the locking and object life-time management aren't
crazy anymore and most controllers now support prope
88 matches
Mail list logo
