Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8272407ybi; Tue, 23 Jul 2019 05:51:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqw9ESSMH8CDRDOQMLwefxIxOiSmDDrlhQuRmNKvXXgO8UIzy5BhNaczi/5nC4LFKfKNUkaz X-Received: by 2002:a63:58c:: with SMTP id 134mr79762255pgf.106.1563886298527; Tue, 23 Jul 2019 05:51:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563886298; cv=none; d=google.com; s=arc-20160816; b=BoGva3HxUL/2T2Gv8KtH4Ywl5kqmANH522rnq+WRxlRn0tgDbn3hQ56OfMANW/V/Tx 9vgQWKLwq8wg0KGUJAEzMa+8EKfbb5EC5LCPPvq36CaMnDBIuEGPhPF/GuzuGWCQoXR1 wTZvyzVymMbSXjXXGCWuRApIVC+GAMgYerc9RJc/vtAY3I4PUwF8DXom5N9zPzCV9UMf Ydy/Rv3uxIkoPaqQtEv2NeMqiCeGfXInumPS3hzYY2ZOCpsrMykCX/FIS8FB3P2yKODE Dm/jX4MXHwJoaiRDObMlLN+o4cuXm+Yaa70GTBYFSlBVIjCGc41xVKqR4PrmYHP7wHcl JOIQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=22UJjcRk/2lGT/hRSqJ5/S0+j7kZgg6IKXcxM0YiLpc=; b=LUgY4+kstuSrxKmlz+HEnQ7oGr+UB8nLIRPAytNGCZ5znQoO0oBJZyGUHk5OLXFAAP n2ZXfizaD4gWbGiX5OL/ZTL+maYrfU0I8bdnCy74O3m0yGc1orLZUmXN8OzT10aoeaGE bjhDDSbigRqXlZhGKqmuzW/0PdfiIv1lVAxFmrZhpt/wkNt8urv6LEs1rkX75XDen1rW J13JlH5KtTw7clkZ2oI4wXUvTljBt7fpsAW6OTKi67LbMDUY5CQWdC91zsHC08Mr/1Yq INJ9y4Kd6Z7KmslCslIQmeQec3bO8bG0/VC8UH1PDilEuLeN8e9hRWG36hKhTDTWTv4e WGNA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MR5t3N1g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x3si11556054pgr.22.2019.07.23.05.51.22; Tue, 23 Jul 2019 05:51:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=MR5t3N1g; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730891AbfGWE3K (ORCPT + 99 others); Tue, 23 Jul 2019 00:29:10 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:39577 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725827AbfGWE3K (ORCPT ); Tue, 23 Jul 2019 00:29:10 -0400 Received: by mail-pg1-f193.google.com with SMTP id u17so18726189pgi.6 for ; Mon, 22 Jul 2019 21:29:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=22UJjcRk/2lGT/hRSqJ5/S0+j7kZgg6IKXcxM0YiLpc=; b=MR5t3N1gfMiPWm1cNEY+2hpVL8X7WUEuq9PC+iLdIp3vivoR4JihR4hn2oH+B8LG8Q TLpw01uk07hfJU8J4mkmHusSM2HJRIZpJjQ4GpoDORuCxdpGD/CDaHqTPAw0ssi/AaXS gZALUDzuohgUR6Ahvc+HTgMRN9ZxkIoCKcroGELR6nGFO810uSqk6VAaRXiXmCzKsqFa u/j6E5vSrkjUpCgs29a1Qm2GyJuovxcP657v/Uf55j13ocmAN/dJ356qY1nlWi6w+nHe OUuzR0K0vJs4xvpBQqY6EhRpmvJ784/Zr8KxPiDmvOjn0BT96Jtt4AMx30eU2idiO1Lh QU0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=22UJjcRk/2lGT/hRSqJ5/S0+j7kZgg6IKXcxM0YiLpc=; b=JPSGHB6wv9ZXeh5ZEvwn4/gqndYwYsLX7CuA7MuWzj5vHVvUM+zodDDDg2cpTARvSh VaR/hbaFXd0+QzjjlwdPrbDyzi4JOa5fMp8r2Iwqyu5oDzhIRlwNDRRcOY+8YxvH95m8 Bpv7yyoCSWozpl55KB6pAxwOCNEIVDdmObpRhhkQsVuWFiuNjAxY0nC/7IzOZwjiBV4f 4FozQkj3jErdoMKwgzf5uWT3GsxGXmbwsxq7zLsDTAJAGjHz8CoxdiJbVymruqkMR5Ts w/L3G33Z7byrrGiNuglzVEZ+tWz5Vdf8mW/HvzB63pE0qR/7V9GdzBo85p2YEoOvFaWN jjRg== X-Gm-Message-State: APjAAAWr3cw4nY8h6+2623umMc09aJt9+P/sc1RCb2t7yPWFX72dqf4B +dVI8/7p5ObDh2Ha+7zPbPVmQQiK2nw= X-Received: by 2002:a63:9e54:: with SMTP id r20mr39915106pgo.64.1563856149447; Mon, 22 Jul 2019 21:29:09 -0700 (PDT) Received: from localhost.localdomain ([49.205.217.198]) by smtp.gmail.com with ESMTPSA id q69sm56424119pjb.0.2019.07.22.21.29.03 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 22 Jul 2019 21:29:08 -0700 (PDT) From: Kaiwan N Billimoria To: linux-kernel@vger.kernel.org Cc: Kaiwan N Billimoria , Tejun Heo , "Peter Zijlstra (Intel)" , Waiman Long , Jens Axboe , Dennis Zhou , Al Viro Subject: cgroups v2: issues faced attempting to setup cpu limiting Date: Tue, 23 Jul 2019 09:58:05 +0530 Message-Id: <20190723042803.21485-1-kaiwan.billimoria@gmail.com> X-Mailer: git-send-email 2.19.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi All, Am facing some issues getting CPU limiting working with cgroups v2. Pl read on for the details; a solution is much appreciated! Env: 5.0.0 Linux kernel on x86_64 Fedora 29 When attempting to setup CPU limiting using cgroups v2, I effectively disabled cgroups v1 by passing cgroup_no_v1=all as a kernel cmdline option. That seems fine and now various controllers (cpu, io, memory, ...) show up under /sys/fs/cgroup/unified/cgroup.controllers. However, doing: # mkdir /sys/fs/cgroup/unified/test1 # echo "+cpu " > /sys/fs/cgroup/unified/test1/cgroup.subtree_control bash: echo: write error: No such file or directory # I understand that this is expected, as the man page on cgroups(7) mentions: "... As at Linux 4.15, the cgroups v2 cpu controller does not support control of realtime processes, and the controller can be enabled in the root cgroup only if all realtime threads are in the root cgroup. (If there are realtime processes in nonroot cgroups, then a write(2) of the string "+cpu" to the cgroup.subtree_control file fails with the error EINVAL. However, on some systems, systemd(1) places certain realtime processes in nonroot cgroups in the v2 hierarchy. On such systems, these processes must first be moved to the root cgroup before the cpu controller can be enabled. ..." My questions are (forgive them if too basic!): how exactly does one 'move realtime processes to the root cgroup'? What are the commands? Next, how does one identify which processes? The ones that have sched policy SCHED_FIFO or SCHED_RR? Would using a utility wrapper make this simpler? (libcgroup, cgmanager, etc) - do they play well with cgroups2? TIA! Regards, Kaiwan. --- amazon author page: https://www.amazon.com/-/e/B07KNJSRJX