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
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 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
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
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: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 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, 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
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
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
68 matches
Mail list logo
