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,
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 with an interim solution for parties who
want to use the ou
46 matches
Mail list logo
