From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752865AbdLEQAy (ORCPT ); Tue, 5 Dec 2017 11:00:54 -0500 Received: from mail-qt0-f169.google.com ([209.85.216.169]:40492 "EHLO mail-qt0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752604AbdLEQAx (ORCPT ); Tue, 5 Dec 2017 11:00:53 -0500 X-Google-Smtp-Source: AGs4zMYbtewfEkwPr1MuOc/QQEh03FSuxw8yu4hrHnGx7dWxYYHJjk+9uNk/CSABAiwrmrAInl4vWA== Date: Tue, 5 Dec 2017 08:00:49 -0800 From: Tejun Heo To: "Michael Kerrisk (man-pages)" Cc: lkml , Lennart Poettering Subject: Re: Writing "+pids" to cgroup.subtree_control flie yields EINVAL Message-ID: <20171205160049.GT2421075@devbig577.frc2.facebook.com> References: <20171204214710.GM2421075@devbig577.frc2.facebook.com> <8fa060d2-07c7-7306-3d93-781c919f24eb@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8fa060d2-07c7-7306-3d93-781c919f24eb@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Michael. On Tue, Dec 05, 2017 at 08:45:19AM +0100, Michael Kerrisk (man-pages) wrote: > b) The reason for my initial problems was this test in > the kernel in cpu_cgroup_can_attach(): > > #ifdef CONFIG_RT_GROUP_SCHED > if (!sched_rt_can_attach(css_tg(css), task)) > return -EINVAL; > #else > /* We don't support RT-tasks being in separate groups */ > if (task->sched_class != &fair_sched_class) > return -EINVAL; > #endif > > I don't have CONFIG_RT_GROUP_SCHED, and the second 'if' was yielding > false because of some SCHED_RR processes that are in some of the nonroot > cgroups created by systemd, namely: I see. Thanks for tracking it down. Yeah, the RT side of things isn't too well thought out yet. > # ps ax -L -o 'pid tid cls rtprio comm'|grep RR > 685 723 RR 99 rtkit-daemon > 972 979 RR 5 alsa-sink-ALC26 > 972 982 RR 5 alsa-source-ALC > 1594 1597 RR 5 alsa-sink-ALC26 > 1594 1600 RR 5 alsa-source-ALC > > So, one solution is to move those processes to the root cgroup, > and then it's possible to write '+pids' to cgroup.subtree_control. You mean '+cpu", right? > Is enabling CONFIG_RT_GROUP_SCHED also a solution? (I have > not had a chance to test that yet.) We aren't yet sure about how we should handle RT and haven't enabled RT part on cgroup2 yet. You can test the same scenario in cgroup1 tho and would have to configure RT shares all along the hierarchy to the leaf cgroup. > Anyway, it seems like this should be documented somewhere in the > kernel Documentation files, since it may be that others will run > into this as well. I'm not quite sure what should be added to the > documentation. Do you have some idea? I think the only thing we can say right now is that RT processes should be in the root cgroup. :( Thanks a lot. -- tejun