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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 8CB31E77188 for ; Wed, 8 Jan 2025 05:05:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 138FB6B0093; Wed, 8 Jan 2025 00:05:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0C2BF6B0095; Wed, 8 Jan 2025 00:05:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E7E726B0096; Wed, 8 Jan 2025 00:05:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id C7D826B0093 for ; Wed, 8 Jan 2025 00:05:10 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 51E3F452AB for ; Wed, 8 Jan 2025 05:05:10 +0000 (UTC) X-FDA: 82983095580.07.4EB608A Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf03.hostedemail.com (Postfix) with ESMTP id AAD1C20004 for ; Wed, 8 Jan 2025 05:05:08 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=1gnw+Ccp; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736312708; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dw5A8koDQ8hNyirhIv1UN+jOVUXYtD48cOnPNAaJh8U=; b=Q4AGQ8JyHakm6Et1JsKiHXD6YU7V7xIu7CkjhSmuWXxmV7iyVSMZ54qZUzN1rcbzTOGxaB mFG57V9Jt8Jr7kZUS6W7qBQqwgZrMYjJ8MdX73Wkn82eRqG1gqlv4eSg3wJKeieMs2luFf yixyyUIXuzXlWxv1TvYojpx9g4paQ+s= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736312708; a=rsa-sha256; cv=none; b=jqJAm7mcLvDJFQ6UPQBKmub3NWwNU7b/DwZppRKJTFfUAYY+KqRQrrK8uhUxTqq7OjV5oJ 2olRHIWsdeHN41XvJf4j/cOiCjESmkkIdN7kYBy0RdkvkXLQqgN296og26ao4Fv7K7y6Eg hmW9nL+b/LX1WHhNzHtE7LHzKtONc8k= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=1gnw+Ccp; spf=pass (imf03.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 19D26A40204; Wed, 8 Jan 2025 05:03:19 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E1C3BC4CED0; Wed, 8 Jan 2025 05:05:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1736312707; bh=hEvWtxDAtzQjDeBsO80USK3yox20DMkjoIkq8Qubp/A=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=1gnw+CcpwFLKGZzmfc1gHMAmEfB77POfvNCjMMEb8MZns0/MX+uHZ8LKBspTbd6aY 0CNS5ip5lcWB2jsS/yy9yM38dbKQskYeSKfYY6flDT7vu82NYRA7tAxHNPh8vLTVdQ p5lZw8+NPpafdyLQaM7e7IC56aWvkadbcfjId6+o= Date: Tue, 7 Jan 2025 21:05:06 -0800 From: Andrew Morton To: Nikhil Dhama Cc: Ying Huang , , , Bharata B Rao , Raghavendra Subject: Re: [FIX PATCH] mm: pcp: fix pcp->free_count reduction on page allocation Message-Id: <20250107210506.3336da0da4332002847c89a3@linux-foundation.org> In-Reply-To: <20250107091724.35287-1-nikhil.dhama@amd.com> References: <20250107091724.35287-1-nikhil.dhama@amd.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: AAD1C20004 X-Stat-Signature: ah91mbyi5dse59y9xy7335pdffjiuf1i X-Rspam-User: X-HE-Tag: 1736312708-352123 X-HE-Meta: U2FsdGVkX1+jdFYpk/h95nJqnw7NdbFFzYyHxXSLG746+0KU0EpXk8B9+wKSUQQBKM4qcbzCZKnnh5D9kuKdKe8t7/OzAkdUaZD+UARVPRpfmd4cQWtAEtjQlWbbpXWfe7gQCC5HdMq23Zu1gqDciOpx4gwrTRo7j0iVfO1Duap8y/V6dYs2PJMo8ItoqUM985mZ35W1NjyNuDORcoyVZNkRtTzXjywQJdX5oE58DyQeRak9DYPK7/qkbg61hG0zmWcUfT8v0gfeB8L7UqK4FAGCKn/nnRir6aSPmPeXzQ7X260IrRcOC8clswc7Thvn36DCB/vB18uqE1o/Io9AgFIQCyQ1n61nH+BaTancNpukCXCwiH+aqzZxPEgxDyF8aQKKu2qul7IR++DwrQ0ixZRRrs0Y++0c1UJpqAExiDU/pYdYelGGWWuNk7Cgf1k3nILHWl0t1a9g6nZnVS6H3+y0VaejAxXg8JMP2VT/mJXHxT8MA/Yg7312l+hd5jUf1x9eXbBcS1IYoozOHai3OxHr+u45opQbsJcYsPBE+NsCfX9Z5H8R2MfNzF68ehXwqvPfdRZ/ZZ3v3nd/+erHDxS3Xzqlr1DIioQeMTQxW/p7ggJiFo1mVHuO+Ee9BXaggD0DwWsw2dXTrKZHxrW/wYjwHBmCd82WMGuzXDMzuFCbu9y7e5DsTzfsmm+0vuYI8T5dt1cMAwM9U/k2BvK7+Is3vRXHg2C6T7OQK8Whfv6LYv6e1LwRAHbZ+RHRfabX82eS74c2MaDjVIkTtNQHP7rqii+xSYASuVY90TiIlPnoeVIpdRvnn7QqiLdnIAb6ZacUhpzBf7bYxnwTP1UFVALdvXufgvJkbn5lgDKXmy8Y86yXGlzDF89lOkjDh0C8GVKZzulGk4ZRJel6iufp2ww+KEKa74KnOAavOK0QB6W+axD16vnSdU+6xMq3qFkLf70K01xtkrDwOu1Um2o L4EFwJH+ MiJafkrBJhPyzZVL4A4Uq4CQUBwtKKUi8l6Fc+TmujldN2qjUfOqJuzSudJCo0JnGlV75Q4ZFj8arkMH8Zsv2k+iatkU8doLR49hCeyf7Kk+fwjyb8GgEo4E/OZLRbm062DVETad7xiic5OJzyshJkODxRq+R3RPefaDzGS7nylmY8Yfmut4KblF0qvGij9NZMEBy3Ybysp4+WJG1XYx2G0/3QANSAqNt4VUndm2Am+R7c1MGLr95srBOpwj7wcPhYuTr0I04WboTpVccvMZgk+OX0lStr/cOc3whnAivHKhgvu+x7v/sfZO4v+njRBRObkjQtj359Qt/x7rFvuuJC27I6+gY4I4qwwlUAfVNketa57hiI+eTo+83Zyj7zfkn+oox X-Bogosity: Ham, tests=bogofilter, spamicity=0.000003, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, 7 Jan 2025 14:47:24 +0530 Nikhil Dhama wrote: > In current PCP auto-tuning desgin, free_count was introduced to track > the consecutive page freeing with a counter, This counter is incremented > by the exact amount of pages that are freed, but reduced by half on > allocation. This is causing a 2-node iperf3 client to server's network > bandwidth to drop by 30% if we scale number of client-server pairs from 32 > (where we achieved peak network bandwidth) to 64. > > To fix this issue, on allocation, reduce free_count by the exact number > of pages that are allocated instead of halving it. The present division by two appears to be somewhat randomly chosen. And as far as I can tell, this patch proposes replacing that with another somewhat random adjustment. What's the actual design here? What are we attempting to do and why, and why is the proposed design superior to the present one? > On a 2-node AMD server, one running iperf3 clients and other iperf3 > sever, This patch restores the performance drop. Nice, but might other workloads on other machines get slower?