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 82E9CC433FE for ; Wed, 9 Feb 2022 03:16:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232387AbiBIDPS (ORCPT ); Tue, 8 Feb 2022 22:15:18 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39620 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S243635AbiBIDOy (ORCPT ); Tue, 8 Feb 2022 22:14:54 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id A3042C0612C1 for ; Tue, 8 Feb 2022 19:14:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1644376492; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=X9DHk6APJIsHE1UI+ceCyZijDLQACCuReEtHVHktgAg=; b=AmXW1nf8BYebvD8R3j31GEa5KmvmSbdZ8Ns7MmDTx3dX+hx4r17ufHkODYgbgPe3yqzioj QSZpLeJk+gmj5QQ5epZUGFtwOWvSMqub2zv5GImnSo8eoLfUvFt72+H/vivHS9EuaE4jtv G9GwL4oE4Wf3T6hPL57IPLgxWoHcTI0= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-533-TMv76d40NiuumRdfoHQ9zA-1; Tue, 08 Feb 2022 22:14:49 -0500 X-MC-Unique: TMv76d40NiuumRdfoHQ9zA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id E426E1091DA0; Wed, 9 Feb 2022 03:14:47 +0000 (UTC) Received: from T590 (ovpn-8-25.pek2.redhat.com [10.72.8.25]) by smtp.corp.redhat.com (Postfix) with ESMTPS id A6EBD4D729; Wed, 9 Feb 2022 03:14:31 +0000 (UTC) Date: Wed, 9 Feb 2022 11:14:23 +0800 From: Ming Lei To: Yu Kuai Cc: tj@kernel.org, axboe@kernel.dk, cgroups@vger.kernel.org, linux-block@vger.kernel.org, linux-kernel@vger.kernel.org, yi.zhang@huawei.com Subject: Re: [PATCH -next] blk-throttle: enable io throttle for root in cgroup v2 Message-ID: References: <20220114093000.3323470-1-yukuai3@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220114093000.3323470-1-yukuai3@huawei.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org Hello Yu Kuai, On Fri, Jan 14, 2022 at 05:30:00PM +0800, Yu Kuai wrote: > RFC patch: https://lkml.org/lkml/2021/9/9/1432 > > There is a proformance problem in our environment: > > A host can provide a remote device to difierent client. If one client is > under high io pressure, other clients might be affected. Can you use the linux kernel storage term to describe the issue? Such as, I guess here host means target server(iscsi, nvme target?), client should be scsi initiator, or nvme host. If not, can you provide one actual example for your storage use case? With common term used, it becomes pretty easy for people to understand & solve the issue, and avoid any misunderstanding. > > Limit the overall iops/bps(io.max) from the client can fix the problem, Just be curious how each client can figure out perfect iops/bps limit? Given one client doesn't know how many clients are connected to the target server. It sounds like the throttle shouldn't be done in client side cgroup, given the throttle is nothing to do with tasks. Maybe it should be done in server side, since server has enough information to provide fair iops/bps allocation for each clients. Thanks, Ming