Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp4162305pxb; Mon, 27 Sep 2021 10:39:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxY0ROBvp/JXm44NO447CGnJLZJ61jw+0HRcxxVNwXkDkRgjb1XK8AfVcVHug+P1ddV2FB0 X-Received: by 2002:a17:906:719:: with SMTP id y25mr1479009ejb.264.1632764376474; Mon, 27 Sep 2021 10:39:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632764376; cv=none; d=google.com; s=arc-20160816; b=eoAk6m93qMfzvCdYQM02PMaze7u/LNNNGaglCxrGT3AcIi9xvOErwTShhk5xXYIkk+ dTpN0fCDYTx9dQFbvEvmhuk0hv53IcnI38dx8HYO5kA7Q3g5yNde1K/vX8n9SCLSCRXY HAH1q1T+nDs++2xaATaS5Pm3+3mZbq8hxJfIrR2VAPAW8MwW7TQkOLXo0xlf91uUnV1b dWR6Cmn7IJnIdn8iDFVjpePeDFUEtPmFHeTqJeia5cPHyOZCqmHsJy5U4K6JGOzWHp0T 922XYkRKaYDO5zFt3o0vvPEYsLIX1XtfrgZ2ReX6BaZ9YHXu+zTVvMGtUGJHiWnCULpk mpRA== 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-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:sender:dkim-signature; bh=icdhatsIVMpVj9yFW17RwQuR1S0u1I+iYgg1GU5p9cg=; b=l/wIFEunnBnhwbWoHaeM5tbTQ+EGx32hrGEwVJq5moMyLwmWirt1MiM6kXaS/NHo16 bGyAhPpzQsUmeVgyUh/6iMZLUSVLCOqbqWN6OxvCT+RLTXpvM8x1ijQ3T8/+JPZZil5y 38LTjCkvvwwJmRWcJPYN/Vx9V+bG0KEcdWD15C+CdvGJIfuiqRz5sHCH+UKERzizprjf ksgr6uONskL2jIIZH3JBAFcMUK7nE7/LFI3h1D3g27dKn5eKN6Q3KKygoB4qkt7KKcbk U9letq+pze84fPbrh848s4P1P3Irz+5zLP9FKfOLfT52i0WlA5Yrdfol6qAisyiUST2G 672w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ZMz3hfxw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id w18si19385062ejv.669.2021.09.27.10.39.08; Mon, 27 Sep 2021 10:39:36 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=ZMz3hfxw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 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 S238129AbhI0RjH (ORCPT + 99 others); Mon, 27 Sep 2021 13:39:07 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43928 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237776AbhI0RhY (ORCPT ); Mon, 27 Sep 2021 13:37:24 -0400 Received: from mail-pl1-x634.google.com (mail-pl1-x634.google.com [IPv6:2607:f8b0:4864:20::634]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AA1CFC02C30A; Mon, 27 Sep 2021 10:08:54 -0700 (PDT) Received: by mail-pl1-x634.google.com with SMTP id l6so12208976plh.9; Mon, 27 Sep 2021 10:08:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=icdhatsIVMpVj9yFW17RwQuR1S0u1I+iYgg1GU5p9cg=; b=ZMz3hfxwpz4U36m5O/CYL7j1TR5S3j0rERHxQWLDXoJkRLldkBdniIGZLVHf9Iit5d Ecfe2rMtWI53lH6H7AXxEgdRL/M1bsKthqaf1i/A3XJEpNQqe9UzQLfrrxOboq/hOvYI 4Bwuza8gO3r6TeSr6m+M5Eiv2gzQYeRvyeuwXV7M2uZeVy1hj8m0O3vGG9v8kzUD4MTB PY7nVeQM2AX4z265SOWlctIjaPzpr9PjGT+KrvnYle0zWd5ZXTp1jpaIhwgYWcCLy3HW V0akiE9PrGLppPnC6Lp5xh4hKko3DuVWP7aJ9iISiwNuJbM0Xk/jhJDPOjfOFFbnm7+q AYiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=icdhatsIVMpVj9yFW17RwQuR1S0u1I+iYgg1GU5p9cg=; b=NJuyGIPqOWJDps/otVJqUJHLq9Bn92tXwXa6+mmXTskp8WKhbpfhVG729aAxTE0/Xl oIVPILOVsj3iS9JnzoSs5mbMu0kSd/z/CwVSOBv3HMYIpqZm31YcugfyTamHZtV7nmZy 7IE+HShOQ4isrxxgknf1FcAI7EnREleNceZLhs1h7r7F9w7gNOCyj1fdPu7IxfokK2kg 1T+qKN0Mnyu8DRH1QG45WwogLn1PP/RW6NEIFYDGAYq/ejBSD0MhvLYRgmVApfPdC2i9 r5FuxYpxZzZ3XVnfWwgIhU00CwLtGzhUBT5zuvPtRRhg5VFdGA2CDnYc69zVCzQ+2CNU ba8A== X-Gm-Message-State: AOAM533TUIoHa8N720EQvFsC58QLYaHTGrm95gjbeijcnXCBq8G00Jbx 2CjvGRh1xigFacWuQ4gNsww= X-Received: by 2002:a17:90a:1a42:: with SMTP id 2mr174835pjl.202.1632762533935; Mon, 27 Sep 2021 10:08:53 -0700 (PDT) Received: from localhost (2603-800c-1a02-1bae-e24f-43ff-fee6-449f.res6.spectrum.com. [2603:800c:1a02:1bae:e24f:43ff:fee6:449f]) by smtp.gmail.com with ESMTPSA id k25sm3666216pgt.49.2021.09.27.10.08.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 27 Sep 2021 10:08:53 -0700 (PDT) Sender: Tejun Heo Date: Mon, 27 Sep 2021 07:08:52 -1000 From: Tejun Heo To: Michal =?iso-8859-1?Q?Koutn=FD?= Cc: "yukuai (C)" , Khazhy Kumykov , axboe@kernel.dk, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com Subject: Re: [RFC PATCH] blk-throttle: enable io throttle for root in cgroup v2 Message-ID: References: <20210909140815.2600858-1-yukuai3@huawei.com> <20210917174103.GC13346@blackbody.suse.cz> <37f8c687-8549-104a-2501-532a0cfc9a48@huawei.com> <20210921134414.GE4091@blackbody.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20210921134414.GE4091@blackbody.suse.cz> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Tue, Sep 21, 2021 at 03:44:14PM +0200, Michal Koutn? wrote: > On 2021/09/18 3:58, Khazhy Kumykov wrote: > > (This does also bring up: if this is a useful thing, would it make > > sense to tie to the device, vs. requiring cgroup. We happen to use > > cgroups so that requirement doesn't affect us). > > Good point, That's IMO a better idea, it'd be more consistent with other > resources for which there exist global (cgroup independent) kernel > constraints (e.g. threads-max sysctl, mem= cmdline, cpu hotplug) that > double the root cgroup contraint role. This is why I usually try to push root-cgroup level features outside cgroup because it really doesn't have much to do with cgroups at the root level. For visibility stuff, we do replicate quite a bit in the root level because not doing so becomes too painful for users but for control I'm more hesitant. One side-way solution could be using iocost. It doesn't have root-level control per-se but it does configure per-device attributes which define what the device can and is allowed to do so that it can be used as the basis for weighted fair distribution. Even if IO control is disabled from the root level, it'll still modulate the device according to the parameters. > OTOH, this also deepens the precedent of init NS root cgroup being > special (more special than a container's root cgroup). While it does seem like an aesthetical wrinkle, I don't think this is a practical problem. System root being different is a given whether aesthetically pleasing or not (not the most important but we have CONFIG_CGROUPS after all). I don't think it'll lead anywhere good to try to mask the differences. Thanks. -- tejun