Received: by 2002:a05:7412:5112:b0:fa:6e18:a558 with SMTP id fm18csp847832rdb; Tue, 23 Jan 2024 18:02:30 -0800 (PST) X-Google-Smtp-Source: AGHT+IGT1zEo80V+z+Awl5KF6t/lPFnPnc2CiUcXZ4LmKK7/g2nbHFdBPoFpGc15X1SPkPrS9FMb X-Received: by 2002:a7b:cb16:0:b0:40e:8e3e:5f91 with SMTP id u22-20020a7bcb16000000b0040e8e3e5f91mr609687wmj.128.1706061750499; Tue, 23 Jan 2024 18:02:30 -0800 (PST) ARC-Seal: i=2; a=rsa-sha256; t=1706061750; cv=pass; d=google.com; s=arc-20160816; b=JHhY1xHt5RAGQGUJpZgofFjWORoJ4cdzpW2d+ts9JxiRn0cG/9NhWaI9b+ajdaXVz/ bUw+bj8vUiC7XhYnAoV6XdUHsXPli9K6NxZmnx+KKcoK7/IkEKOHOx2DO95IKHkvyRPY qyUs69rxlUimgP8wpROFonvovl1mNyGtxe4x+G6d+czBKNyL1OQc6/mQ1jkoNqkASjg8 3MySHiE+CmpIbO35prDuyrVKuOKoCjDbQHXP2wGWSjIt5Qa1eDPdLVbvjZAMcHej+hYp QE6+/2flVkGBDfDG+oeHs8O6oR4rZYcU7UIQoXZQgTC0JvF9LCpG20FL3rpW0ir7zkgZ ZYwA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:in-reply-to:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:user-agent:date:message-id:from :references:cc:to:subject; bh=ydJOQeA628cXP22it6IRYIuCsxGuRV0+t3T8zruDB0Y=; fh=+uqlhEH4wyUGgCCEc1TSRg356KzsVCygGs/vrfPAKKo=; b=bqb9fagQA+n3EHojKKeSL/xi10q7W7iQM+Lf91Q9Hz8nT+3FPg/ELAJQjshZGOJcJt vgX91W0zJvilGyES4Xrb6RSt9kmdF+mkh88YELRVIcHfzopRHhtGT+F8bJpICfq0tcgT VTCbF4ID+3yXu/LxBKXjGD9QUpWw9f1dUUT0ZclmKxy20wrNLP0Xefa+n8wGh4H9Pfmf T/b6WCHWEWXfgdsAe2fKak8YObNe9+NBjgReH4/LD1W6AuhSb4yVHQbg37T66Y5LOgtS vk/vgQNoiaPiOciWSpIKeQJIcD+6PUkT31TZVgY5Psyz8ntKmZDmCHwISjoFZK0GLfVQ bu4g== ARC-Authentication-Results: i=2; mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-kernel+bounces-36293-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36293-linux.lists.archive=gmail.com@vger.kernel.org" Return-Path: Received: from am.mirrors.kernel.org (am.mirrors.kernel.org. [147.75.80.249]) by mx.google.com with ESMTPS id t16-20020a056402525000b0055c4c36ceacsi2646887edd.74.2024.01.23.18.02.30 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 23 Jan 2024 18:02:30 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-36293-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249; Authentication-Results: mx.google.com; arc=pass (i=1 spf=pass spfdomain=huaweicloud.com); spf=pass (google.com: domain of linux-kernel+bounces-36293-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) smtp.mailfrom="linux-kernel+bounces-36293-linux.lists.archive=gmail.com@vger.kernel.org" Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by am.mirrors.kernel.org (Postfix) with ESMTPS id A05EA1F26FB4 for ; Wed, 24 Jan 2024 02:02:20 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 198B51FDC; Wed, 24 Jan 2024 02:02:07 +0000 (UTC) Received: from dggsgout12.his.huawei.com (unknown [45.249.212.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 12F471841; Wed, 24 Jan 2024 02:02:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=45.249.212.56 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706061726; cv=none; b=ioTWzCeMk9ro5cfI69PpklN0iAWUBxmPZ3w7Z1deVeD5/4KOL/NBjdpmYyhiWx4KmK1G0ChNOcJn9uH8GtUiRvcE9tVpY0TNEZJP//+LA2s2CktZNcfhWvgYR+jdhtGFTy+hFvT64O7LPs13RSTqg+EBEDxH6y3rhn+2I05fEq4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1706061726; c=relaxed/simple; bh=SEPWJ8KgQvsmRUWmz4Zz8rIbbyoKhc90M56sFjY+iRc=; h=Subject:To:Cc:References:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type; b=kqbcoW1M+b/LGcTQhtSUCYszefan1O0BkmLdONuQvkdZtaL2o1dHz11/QJM5gsCpaF9x0128VHAryv5GfM6T/UbcknlUlAovbZrdcAMHjAz8WEJf0rwif0bgHC2dl4oV9Wc281PtWEC1vOfshkzvrXTBEcdY9nGNDtXnB0GIhzE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com; spf=pass smtp.mailfrom=huaweicloud.com; arc=none smtp.client-ip=45.249.212.56 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=huaweicloud.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huaweicloud.com Received: from mail.maildlp.com (unknown [172.19.163.235]) by dggsgout12.his.huawei.com (SkyGuard) with ESMTP id 4TKRz139rnz4f3js8; Wed, 24 Jan 2024 10:01:49 +0800 (CST) Received: from mail02.huawei.com (unknown [10.116.40.112]) by mail.maildlp.com (Postfix) with ESMTP id 5D19E1A0232; Wed, 24 Jan 2024 10:01:53 +0800 (CST) Received: from [10.174.178.129] (unknown [10.174.178.129]) by APP1 (Coremail) with SMTP id cCh0CgBXdQ6Lb7Bl6CknBw--.43192S2; Wed, 24 Jan 2024 10:01:49 +0800 (CST) Subject: Re: [PATCH 2/5] mm: correct calculation of cgroup wb's bg_thresh in wb_over_bg_thresh To: Tejun Heo Cc: willy@infradead.org, akpm@linux-foundation.org, hcochran@kernelspring.com, mszeredi@redhat.com, axboe@kernel.dk, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20240123183332.876854-1-shikemeng@huaweicloud.com> <20240123183332.876854-3-shikemeng@huaweicloud.com> From: Kemeng Shi Message-ID: Date: Wed, 24 Jan 2024 10:01:47 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=gbk Content-Transfer-Encoding: 7bit X-CM-TRANSID:cCh0CgBXdQ6Lb7Bl6CknBw--.43192S2 X-Coremail-Antispam: 1UD129KBjvJXoWxGF1fJw18Gr4xGF4ktFykAFb_yoW5GrW5pF Z7JrnFyw4DXFs7JFZrKa92qrW0q3y0yF13Xas0kr1UGrnxGF95Kr4ava1Dury5CrnxJr1F yFsxGrykXrWqyFDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUyEb4IE77IF4wAFF20E14v26r4j6ryUM7CY07I20VC2zVCF04k2 6cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rwA2F7IY1VAKz4 vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xIIjxv20xvEc7Cj xVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwVC2z280aVCY1x 0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC0VAKzVAqx4xG 6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr1lOx8S6xCaFV Cjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l42xK82IYc2Ij 64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxVAqx4xG67AKxVWUJVWUGwC20s026x 8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1q6r43MIIYrxkI7VAKI48JMIIF0xvE 2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6xkF7I0E14v26r1j6r4UMIIF0xvE42 xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE14v26r1j6r4UMIIF0xvEx4A2jsIE c7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa7IU1zuWJUUUUU== X-CM-SenderInfo: 5vklyvpphqwq5kxd4v5lfo033gof0z/ on 1/24/2024 4:43 AM, Tejun Heo wrote: > On Wed, Jan 24, 2024 at 02:33:29AM +0800, Kemeng Shi wrote: >> The wb_calc_thresh will calculate wb's share in global wb domain. We need >> to wb's share in mem_cgroup_wb_domain for mdtc. Call __wb_calc_thresh >> instead of wb_calc_thresh to fix this. > > That function is calculating the wb's portion of wb portion in the whole > system so that threshold can be distributed accordingly. So, it has to be > compared in the global domain. If you look at the comment on top of struct > wb_domain, it says: > > /* > * A wb_domain represents a domain that wb's (bdi_writeback's) belong to > * and are measured against each other in. There always is one global > * domain, global_wb_domain, that every wb in the system is a member of. > * This allows measuring the relative bandwidth of each wb to distribute > * dirtyable memory accordingly. > */ > Hi Tejun, thanks for reply. For cgroup wb, it will belongs to a global wb domain and a cgroup domain. I agree the way how we calculate wb's threshold in global domain as you described above. This patch tries to fix calculation of wb's threshold in cgroup domain which now is wb_calc_thresh(mdtc->wb, mdtc->bg_thresh)), means: (wb bandwidth) / (system bandwidth) * (*cgroup domain threshold*) The cgroup domain threshold is (memory of cgroup domain) / (memory of system) * (system threshold). Then the wb's threshold in cgroup will be smaller than expected. Consider following domain hierarchy: global domain (100G) / \ cgroup domain1(50G) cgroup domain2(50G) | | bdi wb1 wb2 Assume wb1 and wb2 has the same bandwidth. We have global domain bg_thresh 10G, cgroup domain bg_thresh 5G. Then we have: wb's thresh in global domain = 10G * (wb bandwidth) / (system bandwidth) = 10G * 1/2 = 5G wb's thresh in cgroup domain = 5G * (wb bandwidth) / (system bandwidth) = 5G * 1/2 = 2.5G At last, wb1 and wb2 will be limited at 2.5G, the system will be limited at 5G which is less than global domain bg_thresh 10G. After the fix, threshold in cgroup domain will be: (wb bandwidth) / (cgroup bandwidth) * (cgroup domain threshold) The wb1 and wb2 will be limited at 5G, the system will be limited at 10G which equals to global domain bg_thresh 10G. As I didn't take a deep look into memory cgroup, please correct me if anything is wrong. Thanks! > Also, how is this tested? Was there a case where the existing code > misbehaved that's improved by this patch? Or is this just from reading code? This is jut from reading code. Would the case showed above convince you a bit. Look forward to your reply, thanks!. > > Thanks. >