From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4C93C54EBD for ; Fri, 13 Jan 2023 00:54:21 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232557AbjAMAyT (ORCPT ); Thu, 12 Jan 2023 19:54:19 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48474 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240216AbjAMAxu (ORCPT ); Thu, 12 Jan 2023 19:53:50 -0500 Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4454D120A8; Thu, 12 Jan 2023 16:53:45 -0800 (PST) Received: by mail-pg1-x533.google.com with SMTP id g68so12862262pgc.11; Thu, 12 Jan 2023 16:53:45 -0800 (PST) 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:message-id :reply-to; bh=LFhlmdG7Cx41399yo/ozHBL4wwrrh2PAewE6ufP94qA=; b=i6ekoKSewTItPgRE2QdLfrvZixqAENBhz4Yj1/vL3BIQX1WDTpF0k3GyYEmg0KIHxA wj+1HMU7ALqFSNrA9RlqGF4D/uEBUivlqxRFfFOol7sG1QIJ1Sw2zxDYHbNQIys/Qsky 0NFmblrpzx0KKcGh8kB+gjKI8HWtpVlNhmvIdyqXpDUvEnmzDJXr7Od4S3iqm/kBPJFZ vh4y1phX2awKQOOPubl5cOJ3nzq2TOqpX3SUlgiRM9D7awAY5ju8+KGxseEdOdDZZsoa fltbWpnTBk5i6j0UldFDab4ttCBFzpQSgO25zUk2bw5vHS/A6x2A/K5WVpUVGXOfc1WB PCCQ== 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:message-id:reply-to; bh=LFhlmdG7Cx41399yo/ozHBL4wwrrh2PAewE6ufP94qA=; b=sPNER0SSxSLZ2OMAITrOsXnXdf7Amug05ta/Dn8xiiFuX9GYqK2/w+nUc69xs1Ex/+ qR457qz4+dgGC3YS9gNq0RLBXDJiuaIGdoAuoWilhomfGBui2O1xo08yYy+zgLoGmmjO XRJTLLLXS0LxAkfDh6HIZMVGjBt5EqZNyDUuvfk3Hw5zJB1UnplvF+wZmlS4vrF5EvK3 vEGbBKuahzL6B2IYSEHugQK/qHVDG4ItWZV8GKrXfJW9JlbLvQiUxYY1cORd/0GxrANS RKLyEG+0Olw3CvHrUTLgYqdK8Ox7HdF0Ij73YkuTZbPvj7369mhe+tMzAHm8kAmb6qFF qFgw== X-Gm-Message-State: AFqh2kq7ugmShcpvZl4i+Lt4S0o4FWiJ93FqNtVsKF8oI8MQO2LHCSbU psXm9WcAouwFJ7qHbLXZFBY= X-Google-Smtp-Source: AMrXdXu1X9KPr22ssxKflYXC/u/tn02ODq8xROkMYqYHhkQZxtO2R5++OCViQ3yaiUe/98rn3BkSUQ== X-Received: by 2002:a05:6a00:993:b0:581:c2d3:dc5e with SMTP id u19-20020a056a00099300b00581c2d3dc5emr67010322pfg.11.1673571224295; Thu, 12 Jan 2023 16:53:44 -0800 (PST) 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 w9-20020a628209000000b0058a72925687sm6065388pfd.212.2023.01.12.16.53.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Jan 2023 16:53:43 -0800 (PST) Sender: Tejun Heo Date: Thu, 12 Jan 2023 14:53:42 -1000 From: Tejun Heo To: Yu Kuai Cc: hch@infradead.org, josef@toxicpanda.com, axboe@kernel.dk, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com, "yukuai (C)" Subject: Re: [PATCH v2 1/2] blk-iocost: add refcounting for iocg Message-ID: References: <7dcdaef3-65c1-8175-fea7-53076f39697f@huaweicloud.com> <875eb43e-202d-5b81-0bff-ef0434358d99@huaweicloud.com> <53b30ac8-d608-ba0b-8b1b-7fe5cfed6d61@huaweicloud.com> <4aeef320-c6c8-d9b4-8826-d58f00ea6264@huaweicloud.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4aeef320-c6c8-d9b4-8826-d58f00ea6264@huaweicloud.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, On Thu, Jan 12, 2023 at 02:18:15PM +0800, Yu Kuai wrote: > remove the blkcg_deactivate_policy() from rq_qos_exit() from deleting > the device, and delay the policy cleanup and free to blkg_destroy_all(). > Then the policies(other than bfq) can only call pd_free_fn() from > blkg_destroy(), and it's easy to guarantee the order. For bfq, it can > stay the same since bfq has refcounting itself. > > Then for the problem that ioc can be freed in pd_free_fn(), we can fix > it by freeing ioc in ioc_pd_free() for root blkg instead of > rq_qos_exit(). > > What do you think? That would remove the ability to dynamically remove an rq_qos policy, right? We don't currently do it but given that having an rq_qos registered comes with perf overhead, it's something we might want to do in the future - e.g. only activate the policy when the controller is actually enabled. So, idk. What's wrong with synchronizing the two removal paths? blkcg policies are combinations of cgroups and block device configurations, so having exit paths from both sides is kinda natural. Thanks. -- tejun