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
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
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
On Wed, Mar 4, 2015 at 5:08 AM, David Lang da...@lang.hm 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
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
>
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
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
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
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
Tejun Heo tj@... 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
Serge Hallyn 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 tj@... 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
Tejun Heo tj@... 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 tasks
Tejun Heo tj@... 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
Serge Hallyn 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
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
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
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 place my tasks
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
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 you use that
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
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 the problems ONCE.
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
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
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
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 at
On Wed, 3 Jul 2013, Kay Sievers wrote:
On Wed, Jul 3, 2013 at 1:57 AM, Thomas Gleixner t...@linutronix.de 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
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 either a thin
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
>> >
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
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 by
On Wed, Jul 3, 2013 at 1:57 AM, Thomas Gleixner t...@linutronix.de 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
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
On Sun, Jun 30, 2013 at 12:39 PM, Lennart Poettering
lpoet...@redhat.com 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
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
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 care.
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
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
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
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
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,
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
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
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
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
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
>
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
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
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
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
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
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 /c3),
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 via dirt
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 (set
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 interface is
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
subdomain.
On Thu, Jun 27, 2013 at 2:04 PM, Tejun Heo t...@kernel.org 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
On Fri, Jun 28, 2013 at 8:53 AM, Serge Hallyn serge.hal...@ubuntu.com 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,
On Fri, Jun 28, 2013 at 8:05 AM, Michal Hocko mho...@suse.cz 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
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.
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 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 was a very cool
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:10AM +0200, Mike
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, eventually.
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
Come on, now, Lennart. You put a lot of words in my mouth.
On Fri, Jun 28, 2013 at 6:48 PM, Lennart Poettering lpoet...@redhat.com 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
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
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
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
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
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
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
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,
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.
>
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
>
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
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
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?
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? I mean,
On Thu, Jun 27, 2013 at 6:22 AM, Serge Hallyn serge.hal...@ubuntu.com 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
Quoting Tim Hockin (thoc...@hockin.org):
On Thu, Jun 27, 2013 at 6:22 AM, Serge Hallyn serge.hal...@ubuntu.com 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
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 today.
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
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.
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, which knows
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 confident
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
1 - 100 of 175 matches
Mail list logo
