Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp744488pxb; Tue, 8 Feb 2022 01:13:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJz3FqEV+ZrdS7lWzQ0QYiWeCNAz/HPYIDfPiZBYIoZr1uSvsq7EMlOUeZkh/EahipS6wppV X-Received: by 2002:a17:90a:ad81:: with SMTP id s1mr277908pjq.51.1644311620009; Tue, 08 Feb 2022 01:13:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644311620; cv=none; d=google.com; s=arc-20160816; b=AZiGyQoSqZbczazzjo5jsfBZbOUM5OK+bE0pPJuBjq2AMoKI4LRgRD5oppDbRDM2sH buoHOHWCzarEyYCBdc0Aa5mrHA4mkJdOpJvUJqt+SmX1xwHGrOV56SiFsYgMBy7Ad6LI 8ztr0mYzdyME3o2sAkrDle1dxY99P6shqviPrSVlts6J8VizrHv5wLVFvqGyXgC2D3lN EHmoM2ZlxYkejyHPCIEVdPEWjA5k2gWSKZHFbyg8x91Kj4DTcRK8copP0UpT0BF9hX+S HkwettO4tJvcFHG/V96QZrCnblLlXN1lFGk2nwAPEOmGUkEBWm8YwuzkhpXmWY82gVGN FUxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=IE5J0euHMu3m3g83kCpqCjbcQg+nz/o7zYGH0gwBqDQ=; b=0Ybl4ZqPWe8ObOX1MdcpRp6lOsBukwbSc2luBxU19KzkfUj+hwFWV1TgILXis+yurH 7gV+zPxmWlBkDAtOFNbOn/k6RjlqtoHp9KXiPkE26CzFbf3iKImi6J0kevN6ZlSxf+pq xIkkPM5G9aHawRheSeYP+ALEuokHibMXJaNSGKRjWg+qbHA/6TlltZiLfkvTf7AHGtyx XTQgV8tHUULBsmQKjKC8Rt8M7djksAzFXdRgz6o3US6IWZh5JDZIhcZVeA1aA0yHnj4Z 2BG9L0NSooAzSar8FhypvP5/03SQBAPkbvyGPqZP6Z3QQ+TRTAUk//THpSeIsF7lDbKz NFXA== 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id l71si12141831pge.724.2022.02.08.01.13.26; Tue, 08 Feb 2022 01:13:39 -0800 (PST) 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=QUARANTINE sp=QUARANTINE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241926AbiBHBze (ORCPT + 99 others); Mon, 7 Feb 2022 20:55:34 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:43870 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235279AbiBHBzc (ORCPT ); Mon, 7 Feb 2022 20:55:32 -0500 X-Greylist: delayed 1014 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Mon, 07 Feb 2022 17:55:31 PST Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [45.249.212.187]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2C934C061355; Mon, 7 Feb 2022 17:55:30 -0800 (PST) Received: from kwepemi100021.china.huawei.com (unknown [172.30.72.57]) by szxga01-in.huawei.com (SkyGuard) with ESMTP id 4Jt5CM6X25zZdZp; Tue, 8 Feb 2022 09:34:23 +0800 (CST) Received: from kwepemm600009.china.huawei.com (7.193.23.164) by kwepemi100021.china.huawei.com (7.221.188.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Feb 2022 09:38:34 +0800 Received: from [10.174.176.73] (10.174.176.73) by kwepemm600009.china.huawei.com (7.193.23.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2308.21; Tue, 8 Feb 2022 09:38:34 +0800 Subject: Re: [PATCH -next] blk-throttle: enable io throttle for root in cgroup v2 To: Tejun Heo CC: , , , , References: <20220114093000.3323470-1-yukuai3@huawei.com> <235b0757-d322-2b6e-3ab6-ecc8c82f8f1e@huawei.com> From: "yukuai (C)" Message-ID: <32b6949d-60b1-82ce-ae44-1cf089a78276@huawei.com> Date: Tue, 8 Feb 2022 09:38:33 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="gbk"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.176.73] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To kwepemm600009.china.huawei.com (7.193.23.164) X-CFilter-Loop: Reflected X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,NICE_REPLY_A, RCVD_IN_DNSWL_MED,SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham 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 ?? 2022/02/02 1:20, Tejun Heo ะด??: > Hello, > > On Thu, Jan 27, 2022 at 10:36:38AM +0800, yukuai (C) wrote: >> In our case, the disk is provided by server, and such disk can be shared >> by multipul clients. Thus for the client side, the server is a higher >> level parent. >> >> Theoretically, limit the io from server for each client is feasible, >> however, the main reason we don't want to do this is the following >> shortcoming: >> >> client can still send io to server unlimited, we can just limit the >> amount of io that can complete from server, which might cause too much >> pressure on the server side. > > I don't quite follow the "send io to server unlimited" part. Doesn't that > get limited by available number of requests? Hi, Tejun Here I mean that io is not limited through io throttle from client. Of course io must be limited by avaliable number of requests. > ie. if the server throttles, > the in-flight requests will take longer to complete which exhausts the > available requests and thus slows down the client. For example, if we have 8 clients, and available requests is 64. 1) If we don't limit iops, and each client send 64 io to server, some client might have performance issue. 2) If we limit iops to 8 from clients, then server can receive 64 io at most at the same time, both client and server should work fine. 3) If we limit iops to 8 for each client from server, client should work fine, however, server can receive 64 x 8 = 512 io at most at the same time, which might cause too much pressure on the server.(maybe bps is more appropriate to explain the high pressure). Thus I prefer to limit io from client. Thanks, Kuai > That's how it's supposed > to work on the local machine too. > > Thanks. >