On Tue, Oct 04, 2016 at 10:47:17AM -0400, Tejun Heo wrote:
> > cgroup-v2, by placing the system style controllers first and foremost,
> > completely renders that scenario impossible. Note also that any proposed
> > rgroup would not work for this, since that, per design, is a subtree,
> > and theref
Hello, Peter.
On Tue, Sep 06, 2016 at 12:29:50PM +0200, Peter Zijlstra wrote:
> The fundamental problem is that we have 2 different types of
> controllers, on the one hand these controllers above, that work on tasks
> and form groups of them and build up from that. Lets call them
> task-controller
On Fri, 2016-09-30 at 11:06 +0200, Tejun Heo wrote:
> Hello, Mike.
>
> On Sat, Sep 10, 2016 at 12:08:57PM +0200, Mike Galbraith wrote:
> > On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote:
> > > > > As for your example, who performs the cgroup setup and configuration,
> > > > > the application i
Hello, Mike.
On Sat, Sep 10, 2016 at 12:08:57PM +0200, Mike Galbraith wrote:
> On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote:
> > > > As for your example, who performs the cgroup setup and configuration,
> > > > the application itself or an external entity? If an external entity,
> > > > how
Hello,
On Thu, Sep 15, 2016 at 01:08:07PM -0700, Andy Lutomirski wrote:
> With regard to no-internal-tasks, I see (at least) three options:
>
> 1. Keep the cgroup2 status quo. Lots of distros and such are likely
> to have their cgroup management fail if run in a container. I really,
I don't kn
Hello, Austin.
On Mon, Sep 12, 2016 at 11:20:03AM -0400, Austin S. Hemmelgarn wrote:
> > If you confine it to the cpu controller, ignore anonymous
> > consumptions, the rather ugly mapping between nice and weight values
> > and the fact that nobody could come up with a practical usefulness for
> >
On Fri, Sep 16, 2016 at 11:19:38AM -0700, Andy Lutomirski wrote:
> On Fri, Sep 16, 2016 at 9:50 AM, Peter Zijlstra wrote:
> > {1,2} {3,4} {5} seem exclusive, did I miss something? (other than that 5
> > cpu parts are 'rare').
>
> There's no overlap, so they're logically exclusive, but it avoids
On Fri, Sep 16, 2016 at 9:50 AM, Peter Zijlstra wrote:
> On Fri, Sep 16, 2016 at 09:29:06AM -0700, Andy Lutomirski wrote:
>
>> > SCHED_DEADLINE, its a 'Global'-EDF like scheduler that doesn't support
>> > CPU affinities (because that doesn't make sense). The only way to
>> > restrict it is to part
On Fri, Sep 16, 2016 at 09:29:06AM -0700, Andy Lutomirski wrote:
> > SCHED_DEADLINE, its a 'Global'-EDF like scheduler that doesn't support
> > CPU affinities (because that doesn't make sense). The only way to
> > restrict it is to partition.
> >
> > 'Global' because you can partition it. If you r
On Fri, Sep 16, 2016 at 9:19 AM, Peter Zijlstra wrote:
> On Fri, Sep 16, 2016 at 08:12:58AM -0700, Andy Lutomirski wrote:
>> On Sep 16, 2016 12:51 AM, "Peter Zijlstra" wrote:
>> >
>> > On Thu, Sep 15, 2016 at 01:08:07PM -0700, Andy Lutomirski wrote:
>> > > BTW, Mike keeps mentioning exclusive cgr
On Fri, Sep 16, 2016 at 08:12:58AM -0700, Andy Lutomirski wrote:
> On Sep 16, 2016 12:51 AM, "Peter Zijlstra" wrote:
> >
> > On Thu, Sep 15, 2016 at 01:08:07PM -0700, Andy Lutomirski wrote:
> > > BTW, Mike keeps mentioning exclusive cgroups as problematic with the
> > > no-internal-tasks constrain
On Sep 16, 2016 12:51 AM, "Peter Zijlstra" wrote:
>
> On Thu, Sep 15, 2016 at 01:08:07PM -0700, Andy Lutomirski wrote:
> > BTW, Mike keeps mentioning exclusive cgroups as problematic with the
> > no-internal-tasks constraints. Do exclusive cgroups still exist in
> > cgroup2? Could we perhaps jus
On Thu, Sep 15, 2016 at 01:08:07PM -0700, Andy Lutomirski wrote:
> BTW, Mike keeps mentioning exclusive cgroups as problematic with the
> no-internal-tasks constraints. Do exclusive cgroups still exist in
> cgroup2? Could we perhaps just remove that capability entirely? I've
> never understood w
On Wed, Sep 14, 2016 at 1:00 PM, Tejun Heo wrote:
> Hello,
>
With regard to no-internal-tasks, I see (at least) three options:
1. Keep the cgroup2 status quo. Lots of distros and such are likely
to have their cgroup management fail if run in a container. I really,
really dislike this option.
Hello,
On Mon, Sep 12, 2016 at 10:39:04AM -0700, Andy Lutomirski wrote:
> > > Your idea of "trivially" doesn't match mine. You gave a use case in
> >
> > I suppose I wasn't clear enough. It is trivial in the sense that if
> > the userland implements something which works for namespace-root, it
>
On 2016-09-09 18:57, Tejun Heo wrote:
Hello, again.
On Mon, Sep 05, 2016 at 10:37:55AM -0700, Andy Lutomirski wrote:
* It doesn't bring any practical benefits in terms of capability.
Userland can trivially handle the system-root and namespace-roots in
a symmetrical manner.
Your idea of "t
On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote:
> > > As for your example, who performs the cgroup setup and configuration,
> > > the application itself or an external entity? If an external entity,
> > > how does it know which thread is what?
> >
> > In my case, it would be a little script
On Fri, 2016-09-09 at 18:57 -0400, Tejun Heo wrote:
> But, whatever, let's go there: Given the arguments that I laid out for
> the no-internal-tasks rule, how does the problem seem fixable through
> relaxing the constraint?
Well, for one thing, cpusets would cease to leak CPUs. With the no
-inte
Hello, again.
On Mon, Sep 05, 2016 at 10:37:55AM -0700, Andy Lutomirski wrote:
> > * It doesn't bring any practical benefits in terms of capability.
> > Userland can trivially handle the system-root and namespace-roots in
> > a symmetrical manner.
>
> Your idea of "trivially" doesn't match mi
On Mon, Sep 05, 2016 at 10:37:55AM -0700, Andy Lutomirski wrote:
> And I still think that, at least for cpu, nothing at all goes wrong if
> you allow processes to exist in cgroups that have cpu set in
> subtree-control.
cpu, cpuset, perf, cpuacct (although we all agree that really should be
part o
On Sat, Sep 3, 2016 at 3:05 PM, Tejun Heo wrote:
> Hello, Andy.
>
> On Wed, Aug 31, 2016 at 02:46:20PM -0700, Andy Lutomirski wrote:
>> > Consider a use case where the user isn't interested in fully
>> > accounting and dividing up system resources but wants to just cap
>> > resource usage from a s
Hello, Andy.
On Wed, Aug 31, 2016 at 02:46:20PM -0700, Andy Lutomirski wrote:
> > Consider a use case where the user isn't interested in fully
> > accounting and dividing up system resources but wants to just cap
> > resource usage from a subset of workloads. There is no reason to
> > require suc
On Wed, Aug 31, 2016 at 2:07 PM, Tejun Heo wrote:
> Hello,
>
> On Wed, Aug 31, 2016 at 12:11:58PM -0700, Andy Lutomirski wrote:
>> > You can say that allowing the possibility of deviation isn't a good
>> > design choice but it is a design choice with other implications - on
>> > how we deal with c
Hello,
On Wed, Aug 31, 2016 at 12:11:58PM -0700, Andy Lutomirski wrote:
> > You can say that allowing the possibility of deviation isn't a good
> > design choice but it is a design choice with other implications - on
> > how we deal with configurations without cgroup at all, transitioning
> > from
I'm replying separately to keep the two issues in separate emails.
On Mon, Aug 29, 2016 at 3:20 PM, Tejun Heo wrote:
> Hello, Andy.
>
> Sorry about the delay. Was kinda overwhelmed with other things.
>
> On Sat, Aug 20, 2016 at 11:45:55AM -0700, Andy Lutomirski wrote:
>> > This becomes clear whe
On Wed, Aug 31, 2016 at 10:32 AM, Tejun Heo wrote:
> Hello, Andy.
>
>
>> >> I really, really think that cgroup v2 should supply the same
>> >> *interface* inside and outside of a non-root namespace. If this is
>> >
>> > It *does*. That's what I tried to explain, that it's exactly
>> > isomorhpi
Hello, Andy.
On Tue, Aug 30, 2016 at 08:42:20PM -0700, Andy Lutomirski wrote:
> On Mon, Aug 29, 2016 at 3:20 PM, Tejun Heo wrote:
> >> This seems to explain why the controllers need to be able to handle
> >> things being charged to the root cgroup (or to an unidentifiable
> >> cgroup, anyway). T
On Mon, Aug 29, 2016 at 3:20 PM, Tejun Heo wrote:
>> > These base-system operations are special regardless of cgroup and we
>> > already have sometimes crude ways to affect their behaviors where
>> > necessary through sysctl knobs, priorities on specific kernel threads
>> > and so on. cgroup does
Hello, James.
On Sat, Aug 20, 2016 at 10:34:14PM -0700, James Bottomley wrote:
> I can see that process based is conceptually easier in v2 because you
> begin with a process tree, but it would really be a pity to lose the
> thread based controls we have now and permanently lose the ability to
> cr
Hello, Andy.
Sorry about the delay. Was kinda overwhelmed with other things.
On Sat, Aug 20, 2016 at 11:45:55AM -0700, Andy Lutomirski wrote:
> > This becomes clear whenever an entity is allocating memory on behalf
> > of someone else - get_user_pages(), khugepaged, swapoff and so on (and
> > li
On Sat, 2016-08-20 at 11:56 -0400, Tejun Heo wrote:
> > > there are other reasons to enforce process granularity. One
> > > important one is isolating system-level management operations from
> > > in-process application operations. The cgroup interface, being a
> > > virtual filesystem,
On Wed, 2016-08-17 at 13:18 -0700, Andy Lutomirski wrote:
> On Aug 5, 2016 7:07 PM, "Tejun Heo" wrote:
[...]
> > 2. Disagreements and Arguments
> >
> > There have been several lengthy discussion threads [3][4] on LKML
> > around the structural constraints of cgroup v2. The two that
> > affect t
On Sat, Aug 20, 2016 at 8:56 AM, Tejun Heo wrote:
> Hello, Andy.
>
> On Wed, Aug 17, 2016 at 01:18:24PM -0700, Andy Lutomirski wrote:
>> > 2-1-1. Process Granularity
>> >
>> > For memory, because an address space is shared between all threads
>> > of a process, the terminal consumer is a pro
Hello, Andy.
On Wed, Aug 17, 2016 at 01:18:24PM -0700, Andy Lutomirski wrote:
> > 2-1-1. Process Granularity
> >
> > For memory, because an address space is shared between all threads
> > of a process, the terminal consumer is a process, not a thread.
> > Separating the threads of a single
On Aug 5, 2016 7:07 PM, "Tejun Heo" wrote:
>
> Hello,
>
> There have been several discussions around CPU controller support.
> Unfortunately, no consensus was reached and cgroup v2 is sorely
> lacking CPU controller support. This document includes summary of the
> situation and arguments along wi
On Tue, 2016-08-16 at 12:30 -0400, Johannes Weiner wrote:
> On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote:
> > Also, the argument there seems unfair at best, you don't need cpu-v2 for
> > buffered write control, you only need memcg and block co-mounted.
>
> Yes, memcg and block a
Hello, Peter.
On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 10, 2016 at 06:09:44PM -0400, Johannes Weiner wrote:
>
> > [ That, and a disturbing number of emotional outbursts against
> > systemd, which has nothing to do with any of this. ]
>
> Oh, so I'm entirely
On Tue, Aug 16, 2016 at 04:07:38PM +0200, Peter Zijlstra wrote:
> On Wed, Aug 10, 2016 at 06:09:44PM -0400, Johannes Weiner wrote:
>
> > [ That, and a disturbing number of emotional outbursts against
> > systemd, which has nothing to do with any of this. ]
>
> Oh, so I'm entirely dreaming this
On 08/16/2016 10:07 AM, Peter Zijlstra wrote:
On Wed, Aug 10, 2016 at 06:09:44PM -0400, Johannes Weiner wrote:
[ That, and a disturbing number of emotional outbursts against
systemd, which has nothing to do with any of this. ]
Oh, so I'm entirely dreaming this then:
https://github.com/
On Wed, Aug 10, 2016 at 06:09:44PM -0400, Johannes Weiner wrote:
> [ That, and a disturbing number of emotional outbursts against
> systemd, which has nothing to do with any of this. ]
Oh, so I'm entirely dreaming this then:
https://github.com/systemd/systemd/pull/3905
Completely unrelated.
On Fri, 2016-08-12 at 18:17 -0400, Johannes Weiner wrote:
> > > This argument that cgroup2 is not backward compatible is laughable.
> >
> > Fine, you're entitled to your sense of humor. I have one to, I find it
> > laughable that threaded applications can only sit there like a lump of
> > mud si
On Thu, Aug 11, 2016 at 08:25:06AM +0200, Mike Galbraith wrote:
> On Wed, 2016-08-10 at 18:09 -0400, Johannes Weiner wrote:
> > The complete lack of cohesiveness between v1 controllers prevents us
> > from implementing even the most fundamental resource control that
> > cloud fleets like Google's a
On Wed, 2016-08-10 at 18:09 -0400, Johannes Weiner wrote:
> The complete lack of cohesiveness between v1 controllers prevents us
> from implementing even the most fundamental resource control that
> cloud fleets like Google's and Facebook's are facing, such as
> controlling buffered IO; attributing
On Sat, Aug 06, 2016 at 11:04:51AM +0200, Mike Galbraith wrote:
> On Fri, 2016-08-05 at 13:07 -0400, Tejun Heo wrote:
> > It is true that the trees are semantically different from each other
> > and the symmetric handling of tasks and cgroups is aesthetically
> > pleasing. However, it isn't
On Fri, 2016-08-05 at 13:07 -0400, Tejun Heo wrote:
> 2-2. Impact on CPU Controller
>
> As indicated earlier, the CPU controller's resource distribution graph
> is the simplest. Every schedulable resource consumption can be
> attributed to a specific task. In addition, for weight based control,
45 matches
Mail list logo
