Received: by 2002:a05:6359:c8b:b0:c7:702f:21d4 with SMTP id go11csp308683rwb; Mon, 26 Sep 2022 12:39:51 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5s+naMGe75/qh3NDi9MWI53pfCuCg2/BDmdYTIal6X4Bh3W/ZBgitbr0x1DVvPXsfwDPh2 X-Received: by 2002:aa7:864a:0:b0:53f:dcdf:4614 with SMTP id a10-20020aa7864a000000b0053fdcdf4614mr25430537pfo.38.1664221191028; Mon, 26 Sep 2022 12:39:51 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1664221191; cv=none; d=google.com; s=arc-20160816; b=cHm0HxDkqve9ORcIflquAdyNRkFH4VhabSjyKzpvRKFWnnvzZ8nwMyoXUypN5CkO2Y 2lazvtxnx2Fr0pds/7i6ZB2Z8k3ei4b+zm9CNgQn8WdI59OekwKJlQp3KC40TpLqrVP+ 9aHtBatzaIdMOUl5mwI2JPOYc+C/DdISVLCD10MOIbGQfVdBjL3EoUGSNJpjUyh+Fo4y KvBx0vliJbOOIyblitpXnB7PCsX+B/gA1ZdJXnRaFIog1WEwyXdJ38ja5A6W+SWF4MV6 237yz/yCSdyfq7qOpR2rBpGyGMXsgpcv4m+PMqU0JfpEPFCunWxrChBBwoAYjbObEi+N mTZQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:dkim-signature; bh=Dyqc18f7tvm496eP3xU3ct8tqy6/7/TepuJUSfhcP1Y=; b=ztS8iGNM1w1kToSA9i/J55pWliH+tZyEPPkMu5gWG3WGZEgNS4oAXCZKaz1q6dmj2a FgMj81EjpDZ/kOs5WVuA+8rcXJ5dPLPAJU7QrLA5QJTQJltfUQZzoxtvuGGhRX7hWEo9 R1Da7rTPAAa653OcVfWe0Uc6V8z8WdjXl63cpS9RQ3JrHRBPp7jYYSJgRHSmT/LLH/rR r2FFtkAhMyYK7e/f6OP3v3yWPpF3V7DZkCw2YRcRQGorU0oaMXASh72wY530t/hzWbC3 sf+DHPoqzpiQvxzF+cte3UtPF0zfiXAJeWeW6sMc6AeF4Q1RdBrdqtlMDJsQyY8zaJ6f BrCQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pMeDGfIZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id j9-20020a17090a2a8900b001fac75257fbsi11391028pjd.161.2022.09.26.12.39.38; Mon, 26 Sep 2022 12:39:51 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=pMeDGfIZ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229732AbiIZTMN (ORCPT + 99 others); Mon, 26 Sep 2022 15:12:13 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51114 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229457AbiIZTMM (ORCPT ); Mon, 26 Sep 2022 15:12:12 -0400 Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9673A88DCB; Mon, 26 Sep 2022 12:12:11 -0700 (PDT) Received: by mail-pg1-x52b.google.com with SMTP id c7so7390458pgt.11; Mon, 26 Sep 2022 12:12:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:from:to:cc:subject:date; bh=Dyqc18f7tvm496eP3xU3ct8tqy6/7/TepuJUSfhcP1Y=; b=pMeDGfIZ6SzFPBlN73M0ajQB/RGF4w2o+TyqK7pty1VyKbu13iZcGmLUl9Bi8c2hPZ eKhAKnp3n2f08OHQVHBk0cq8xo4bA/d/+AWNzbMxyzInJS+HoYC1k7Akvf8aYWF6y/LW wi5drJ1GstBDZBqr7IBiPDOXPWIee6npCJJtfvXUM1tAnalK/5YXC3k/HJB20y8gAufg gOXNdlPoOhFdxQ42BdVqVm8eYolU6FyOpYZN/YR3iqp5eEfmcYK6nWnTM6xergGyXbOQ +yOOkfw952go/oFjAV9ndq0eQKqhzSt7kVN5eWnT2Lv0KNiACRPbhJoopFAZY8RnRRAn 0gsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:sender:x-gm-message-state:from:to:cc :subject:date; bh=Dyqc18f7tvm496eP3xU3ct8tqy6/7/TepuJUSfhcP1Y=; b=1xNzjPEOGKWclsN6NnNfd514BKC4hMkr/E3CHKEchUqkLQICWU3i8M3K5bQf6XuLDR Rp9ZfFfmbnsPeS/BUKU+Ii6NZvnbLATksxbU2nZODZSaB+XgHqeVgeDEKq3YL1/61HVi Pt9P76JZWlKGLR+dBiaVyTfG3atwv0HWTfoX85AdY4Yo7xhWvpbP5KVwnRGcC8i2duvQ 0aOl6/dZMj/4eYr7lM4Dl6cXooPkLQ4ijvejUWr9nyD5JtmP95hXwW7EdoQ29Ro0GXrS g3OS92fXMa7OsXmrHatw1vJ1R61wMxdYDek0S/0j4lJvbk31Z4bSA/4XsZCyRbNc/1ut 4Dpw== X-Gm-Message-State: ACrzQf2QqbgdH1fbzADCiuqi7SX7UJuMI7Yxhou/UQ5VR/CIbhQvP7Or QZjIa5+ETVL9MOBNKoga6vs= X-Received: by 2002:a63:85c3:0:b0:43a:4c05:c313 with SMTP id u186-20020a6385c3000000b0043a4c05c313mr21577436pgd.418.1664219530946; Mon, 26 Sep 2022 12:12:10 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-a7fa-157f-969a-4cde.res6.spectrum.com. [2603:800c:1a02:1bae:a7fa:157f:969a:4cde]) by smtp.gmail.com with ESMTPSA id u13-20020a170902714d00b00178aaf6247bsm11647718plm.21.2022.09.26.12.12.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Sep 2022 12:12:10 -0700 (PDT) Sender: Tejun Heo Date: Mon, 26 Sep 2022 09:12:08 -1000 From: Tejun Heo To: "lujialin (A)" Cc: peterz@infradead.org, Zefan Li , cgroups@vger.kernel.org, LKML Subject: Re: [question] Is it possible for userspace program to control cpu usage time of RT process through cgroup2 now? Message-ID: References: <0a83dcd5-b7fd-811c-b8d2-062115fa8c94@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0a83dcd5-b7fd-811c-b8d2-062115fa8c94@huawei.com> X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_EF,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Sat, Sep 24, 2022 at 05:26:20PM +0800, lujialin (A) wrote: > Cgroup2 dose not support controling real-time processes and the cpu > controller can only be enabled when all RT processes are in the root cgroup. > > RT stuff was being overhauled when cpu controller interface for cgroup > unified hierarchy was being implemented in 2017. It was decided that we > would like to wait till the RT side settles down and proceed with an > interface that better matches RT. > > Is it possible for userspace program to control cpu usage time of RT process > through cgroup2 now? If not, how is the current state looking and is there > any proposed solution? Not right now. The hard allocation model is pretty challenging to work with on cgroup1 - they get enabled when cpu controller gets enabled and being hard allocations, not allocating any prevents the cgroups from using RT at all while allocating by default takes away from what others can use whether that allocation is used or not, so some distros turned them off last I checked. Overall, I'm not sure hard allocations done this way is all that useful to manage hierarchically given that the resource has to be hard partitioned anyway. Can you describe your usecase? Thanks. -- tejun