Message ID | 20230322135959.1998790-1-dietmar.eggemann@arm.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:604a:0:0:0:0:0 with SMTP id j10csp2366711wrt; Wed, 22 Mar 2023 07:17:59 -0700 (PDT) X-Google-Smtp-Source: AK7set8wg4/40H3Fci7/yyMXsoUtVD8H0nXoLLRvs0m/Wdya48Eqhsdpm+sGSdlb5yrpKVe31zlO X-Received: by 2002:a17:90b:3b45:b0:237:97a3:1479 with SMTP id ot5-20020a17090b3b4500b0023797a31479mr4262413pjb.28.1679494679631; Wed, 22 Mar 2023 07:17:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1679494679; cv=none; d=google.com; s=arc-20160816; b=jrbix4PuI2pMoxHUNtPaB5qXM3qDpBOGASBaozNxc2qzsqCGd7xY/U9TOVjbWbNL05 Gk1bpQ9KSW+7sBbZyt7x+0mWZX8vdc3E8RexFIndopwGaQvR7OyA2c251oZYHrmtMYbn 9mMTL25L1EjFUZtw67ftBOrR+qHdEVkgEea3MwsyK9dTUB/F9AY6Du81PJEbZ7mtQF0d emgFmYnk46AwDOGxghUWBlowiZbfJ1KYHcqj729WRY0CDjkUs69No0KBrD2kwEXFIZ2/ 8LjE5Z0lHjN3v6C7uTrUx6cLf/3yscRNuMPi6xPwWRtP2OiIMAJ+tjEyK0mHXEpv54rb pYzA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=QeV/4pStBX06yUhhDME7pBubEPm2yYcKchFLAtihrJ4=; b=zx4s4XeQNttyyK0Hq/l0uHJAR8/ivpaJ2CAlQXk+vRma7ZSYQGvSEjHSN6JCiBe7Qw EFNBkLcPZHSDJ5Iw+Ogb6VgyijgKQJqIRH/qhe9dsPo3bq9Nyi2lCgjhh3LOVBryG2Bp X2MtOWEPP+5W//mE7YsvOsfaWCf+oIIO1LJOx2rCoedaLY+zzU8CQPCrTuAPC9IUhiu5 ESfDfIrSaVZwGGTa6vIQQ1AMbbdOfb30sQuG/xNAnonIiAIFbxHJWxPOwj0pPSb++C0z BLncUztYLlvUiKyEaeSXU/FdLCJOOPmHnCX1/mhIw09I8GDojejGPRSlA4a+sDJl6YLX VbDQ== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id x4-20020a17090a1f8400b00233fdabf0e6si21115681pja.12.2023.03.22.07.17.46; Wed, 22 Mar 2023 07:17:59 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=arm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230333AbjCVOAO (ORCPT <rfc822;pusanteemu@gmail.com> + 99 others); Wed, 22 Mar 2023 10:00:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:42182 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229806AbjCVOAM (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 22 Mar 2023 10:00:12 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 4735626B1; Wed, 22 Mar 2023 07:00:09 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id D91B24B3; Wed, 22 Mar 2023 07:00:52 -0700 (PDT) Received: from e125579.fritz.box (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 42C033F71E; Wed, 22 Mar 2023 07:00:06 -0700 (PDT) From: Dietmar Eggemann <dietmar.eggemann@arm.com> To: Ingo Molnar <mingo@kernel.org>, Peter Zijlstra <peterz@infradead.org>, Juri Lelli <juri.lelli@redhat.com>, Waiman Long <longman@redhat.com>, Tejun Heo <tj@kernel.org>, Zefan Li <lizefan.x@bytedance.com>, Johannes Weiner <hannes@cmpxchg.org>, Hao Luo <haoluo@google.com> Cc: Steven Rostedt <rostedt@goodmis.org>, Vincent Guittot <vincent.guittot@linaro.org>, Daniel Bristot de Oliveira <bristot@redhat.com>, Luca Abeni <luca.abeni@santannapisa.it>, Tommaso Cucinotta <tommaso.cucinotta@santannapisa.it>, Qais Yousef <qyousef@layalina.io>, Wei Wang <wvw@google.com>, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: [RFC PATCH 0/2] sched/cpuset: Fix DL BW accounting in case can_attach() fails Date: Wed, 22 Mar 2023 14:59:57 +0100 Message-Id: <20230322135959.1998790-1-dietmar.eggemann@arm.com> X-Mailer: git-send-email 2.25.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_NONE autolearn=unavailable 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761077813487275202?= X-GMAIL-MSGID: =?utf-8?q?1761077813487275202?= |
Series |
sched/cpuset: Fix DL BW accounting in case can_attach() fails
|
|
Message
Dietmar Eggemann
March 22, 2023, 1:59 p.m. UTC
I followed Longman's idea to add a `deadline task transfer count` into cpuset and only update the `dl task count` in cpuset_attach(). Moreover, I switched from per-task DL BW request to a per-cpuset one. This way we don't have to free per-task in case xxx_can_attach() fails. The DL BW freeing is handled in cpuset_cancel_attach() for the case `multiple controllers and one of the non-cpuset can_attach() fails`. Only lightly tested on cgroup v1 with exclusive cpusets so far. Dietmar Eggemann (2): sched/deadline: Create DL BW alloc, free & check overflow interface cgroup/cpuset: Free DL BW in case can_attach() fails include/linux/sched.h | 4 ++- kernel/cgroup/cpuset.c | 55 +++++++++++++++++++++++++++++++++++++---- kernel/sched/core.c | 19 +++----------- kernel/sched/deadline.c | 53 +++++++++++++++++++++++++++++---------- kernel/sched/sched.h | 2 +- 5 files changed, 97 insertions(+), 36 deletions(-)
Comments
Hi, On 22/03/23 14:59, Dietmar Eggemann wrote: > I followed Longman's idea to add a `deadline task transfer count` into > cpuset and only update the `dl task count` in cpuset_attach(). > > Moreover, I switched from per-task DL BW request to a per-cpuset one. > This way we don't have to free per-task in case xxx_can_attach() fails. > > The DL BW freeing is handled in cpuset_cancel_attach() for the case > `multiple controllers and one of the non-cpuset can_attach() fails`. > > Only lightly tested on cgroup v1 with exclusive cpusets so far. This makes sense to me. Thanks for working on it! Guess I might incorporate these in my (RFC) series and re-post the whole lot? Best, Juri
On 23/03/2023 10:33, Juri Lelli wrote: > Hi, > > On 22/03/23 14:59, Dietmar Eggemann wrote: [...] > This makes sense to me. Thanks for working on it! > > Guess I might incorporate these in my (RFC) series and re-post the whole > lot? Yes, please do so.