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 B48DDFA373D for ; Tue, 1 Nov 2022 10:40:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 31D936B0072; Tue, 1 Nov 2022 06:40:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2CD9E6B0073; Tue, 1 Nov 2022 06:40:45 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BC576B0074; Tue, 1 Nov 2022 06:40:45 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 0BDF06B0072 for ; Tue, 1 Nov 2022 06:40:45 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id CCED31C6826 for ; Tue, 1 Nov 2022 10:40:44 +0000 (UTC) X-FDA: 80084530008.30.9004E20 Received: from outbound-smtp52.blacknight.com (outbound-smtp52.blacknight.com [46.22.136.236]) by imf22.hostedemail.com (Postfix) with ESMTP id 0A0BAC001F for ; Tue, 1 Nov 2022 10:40:43 +0000 (UTC) Received: from mail.blacknight.com (pemlinmail04.blacknight.ie [81.17.254.17]) by outbound-smtp52.blacknight.com (Postfix) with ESMTPS id 329D6FAD40 for ; Tue, 1 Nov 2022 10:40:42 +0000 (GMT) Received: (qmail 7548 invoked from network); 1 Nov 2022 10:40:42 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[84.203.198.246]) by 81.17.254.9 with ESMTPSA (AES256-SHA encrypted, authenticated); 1 Nov 2022 10:40:42 -0000 Date: Tue, 1 Nov 2022 10:40:40 +0000 From: Mel Gorman To: Chen Wandun Cc: akpm@linux-foundation.org, vbabka@suse.cz, linux-mm@kvack.org, linux-kernel@vger.kernel.org, wangkefeng.wang@huawei.com Subject: Re: [PATCH] mm: fix pcp count beyond pcp high in pcplist allocation Message-ID: <20221101104040.o6gqtyyd5d4pkhle@techsingularity.net> References: <20221024134146.3442393-1-chenwandun@huawei.com> <20221024145555.oaoisy6m723h4axc@techsingularity.net> <20221025131959.sd47fipimhehf76i@techsingularity.net> <316bc0a2-34d9-e485-11d2-f3dffd0fdea4@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <316bc0a2-34d9-e485-11d2-f3dffd0fdea4@huawei.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667299244; 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; bh=kDcCZaeFtmSiIUtLe4t5gqueFd8rVVEzcQ4RqkIJA/Q=; b=k9Qp/kJWxCG7XxvHRIQiI3NZzNLhMcuw+LOasFpbMHKsO8POKux5SJTUXb90aMSESKWt1i gZo6Gz0/V5fIHG9ymPQTHvDLve/sJ7mAhtxfh2WIgsWNujybhTWehB4WOQard2yttR/xNM gtyOaYxyZEQqj9U0P6a7dN73Co4q7Gk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.236 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667299244; a=rsa-sha256; cv=none; b=XOg6ccagJc9t/4p72UxV3nv7qd/8yTPoZZbeuRcGTHsgrqLUcGblhOr1nA8tmJnpmprJic YZm2m/wCR6G5FJxnAXsRtb+j9qTvLVuGHh28Adm8nfKAuqOmzuK0B5LcnPTtWxzNBEd7GW mdCnb+iwyaZ6+t/SzFgzVGHm2mu4m5k= X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 0A0BAC001F X-Rspam-User: Authentication-Results: imf22.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf22.hostedemail.com: domain of mgorman@techsingularity.net designates 46.22.136.236 as permitted sender) smtp.mailfrom=mgorman@techsingularity.net X-Stat-Signature: r1b6o6h4s5eai1dffai8wc3renbyjrcx X-HE-Tag: 1667299243-488865 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Oct 31, 2022 at 11:37:35AM +0800, Chen Wandun wrote: > > > > As is, the patch could result in a batch request of 0 and > > >  I foget this, the patch need some improve, thanks. > > > > > > > fall through to allocating from the zone list anyway defeating the > > > > purpose of the PCP allocator and probably regressing performance in some > > > > csaes. > > > Same as I understand???how about set high/batch for each order in pcplist??? > > Using anything would than (X >> order) consumes storage. Even if storage > > was to be used, selecting a value per-order would be impossible because > > the correct value would depend on frequency of requests for each order. > > That can only be determined at runtime and the cost of determining the > > value would likely exceed the benefit. > > Can we set a experience value for pcp batch for each order during init > stage? I'm not sure what you mean by "experience value" but maybe you meant experimental value? > If so we can make accurately control for pcp size. Nowdays, the size of each > order in pcp list is full of randomness. I dont konw which scheme is better > for performance. > It is something that could be experimented with but the main question is -- what should those per-order values be? One option would be to enforce pcp->high for all high-order values except THP if THP is enabled. That would limit some of the issues with pcp->high being exceeded as even if two THPs are refilled, one of them is allocated immediately. I wasn't convinced it was necessary when implementing high-order PCP support but it could be evaluated. -- Mel Gorman SUSE Labs