From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 9056213B797 for ; Wed, 8 Jan 2025 05:05:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736312707; cv=none; b=LqH8YpEYugsRfk+07/vsqqb+srWA9/AUWDXJpGBIPBSBN4APSa2G+oUCKVxjy/y2k3E9iwj1YmjbobSCmiToM1y4Dj+PGvCy7eKhxsqiUqQG+NYIR1oU5OcqVtrpRo2brYHqze+n9zH3xucDvSQ5h/vILUCsUPTWiK0ar3pu1aY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736312707; c=relaxed/simple; bh=hEvWtxDAtzQjDeBsO80USK3yox20DMkjoIkq8Qubp/A=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=tOE/RF1jolV3cJt+xs/8TGqU2NNQujDJ6QqrPvrNj4IETxlS10NAI0UWyaz3KFvWeshkuGb7Ujr+UGaPMIwq5zhhRxBM2cWzpBL23r2brqH9UOhQz7oCmhxTBGSo4ZFCGh3B8qkPWKM93MshGMujjYetrL4o7fZpVU90OOtD6q4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=1gnw+Ccp; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="1gnw+Ccp" 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) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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?