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 6A8D3C19776 for ; Fri, 28 Feb 2025 11:02:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A890F280004; Fri, 28 Feb 2025 06:02:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A3920280001; Fri, 28 Feb 2025 06:02:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 88BB7280004; Fri, 28 Feb 2025 06:02:01 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 6B3C1280001 for ; Fri, 28 Feb 2025 06:02:01 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 2A2311C7DCA for ; Fri, 28 Feb 2025 11:02:01 +0000 (UTC) X-FDA: 83169063642.03.F92016A Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf07.hostedemail.com (Postfix) with ESMTP id B56DB40015 for ; Fri, 28 Feb 2025 11:01:58 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=TORL20zd; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=rePhrVR8; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=EfvuF9Kp; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=iZFI9tgS; dmarc=none; spf=pass (imf07.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740740519; a=rsa-sha256; cv=none; b=z0hJZNZMQP2NKuZu14jJOLRFFJcNxMCK+puYpFAnmxz+WZE9O3DQ2TZbiTMSMpzEVUvQ3S 3T/RbMbTJajhGfHdmgOHHRe+fR/jmzzqzWmkH8QIhFTp027trk/LMami5jNUvbsQdADYcd gqd9sKetQZXlX+YhF2q6vIQ3tbDbYD4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=TORL20zd; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=rePhrVR8; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=EfvuF9Kp; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=iZFI9tgS; dmarc=none; spf=pass (imf07.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740740519; 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=5xYsE7kl/f83kURL9obXqUw2kpX8E5zSQwx+IhLd9K8=; b=euFcg6Sc+fxIoQtsVqcW6IQVQuo5q9Gk7wDiWcM/Hmp7fTQ8OYsmwTMjCCe6ts/DcNfipY JAbB3KQDAYEPHzywSZC3KolRRotaU1L8rpqG0kVH6HL3r5JRYCUn0LAwHlf79tWc8eaQGz eHiUFry+OG29y21ZaSnCd8GOqKCaoLQ= Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id F19EB21165; Fri, 28 Feb 2025 11:01:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740740517; h=from:from:reply-to: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:autocrypt:autocrypt; bh=5xYsE7kl/f83kURL9obXqUw2kpX8E5zSQwx+IhLd9K8=; b=TORL20zd+sC0lUWxxEkVFJFdvcXAUmh/FefB9aLU1rNrFQispbclnlXuBv2C3c2SKqF+Qx R83DPgMYw+KF0h0zLvRy8dvH0Xgxuka56pdSZGyNwm0KYER1ReDVCO2VE0cO5dkx1H4L+b n42XKTH+UNdnuNvdadNA+LqRrlmIf1M= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740740517; h=from:from:reply-to: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:autocrypt:autocrypt; bh=5xYsE7kl/f83kURL9obXqUw2kpX8E5zSQwx+IhLd9K8=; b=rePhrVR8C5/uWE/xk4lv7svUkI5Tezrr8Ga+BBYgftK9rnq6ifWYrNYGZxprZex1FHJxzS t4yoguD+sLIugnCQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1740740516; h=from:from:reply-to: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:autocrypt:autocrypt; bh=5xYsE7kl/f83kURL9obXqUw2kpX8E5zSQwx+IhLd9K8=; b=EfvuF9KpmeySxU2JAzozbP3omJvZ9Yr1mU1L6+Spo3V4j+XQ6tEBmw2Dtq8tz5ab7TdEpp xodLj3FvnsWlAnaajEw0GnC8JHZozZwZ+se8yoVOMqOwH37uIJXoR6/XlJEt7vF3mLJYvM 9kYGnU22VUQnJJ+NoD1h7eUzZQT2L0k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1740740516; h=from:from:reply-to: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:autocrypt:autocrypt; bh=5xYsE7kl/f83kURL9obXqUw2kpX8E5zSQwx+IhLd9K8=; b=iZFI9tgSVhcICIbYA2y+5pGdpZ6MMoN7OjLt4CC1CJFTORSAzWfxNcRAvGN/3ACm4QQDPr IwOd91LoTBb9t4Dg== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id D66861344A; Fri, 28 Feb 2025 11:01:56 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id ORfIMaSXwWfTbQAAD6G6ig (envelope-from ); Fri, 28 Feb 2025 11:01:56 +0000 Message-ID: <047cdda5-d6bd-4ce0-8905-f1bc00153d6d@suse.cz> Date: Fri, 28 Feb 2025 12:01:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm/page_alloc: make the maximum number of highatomic pageblocks resizable Content-Language: en-US To: zhongjinji@honor.com, akpm@linux-foundation.org, Mel Gorman , Johannes Weiner , Brendan Jackman Cc: yuzhao@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, rientjes@google.com, yipengxiang@honor.com, liulu.liu@honor.com, feng.han@honor.com References: <20250226024126.3718-1-zhongjinji@honor.com> From: Vlastimil Babka Autocrypt: addr=vbabka@suse.cz; keydata= xsFNBFZdmxYBEADsw/SiUSjB0dM+vSh95UkgcHjzEVBlby/Fg+g42O7LAEkCYXi/vvq31JTB KxRWDHX0R2tgpFDXHnzZcQywawu8eSq0LxzxFNYMvtB7sV1pxYwej2qx9B75qW2plBs+7+YB 87tMFA+u+L4Z5xAzIimfLD5EKC56kJ1CsXlM8S/LHcmdD9Ctkn3trYDNnat0eoAcfPIP2OZ+ 9oe9IF/R28zmh0ifLXyJQQz5ofdj4bPf8ecEW0rhcqHfTD8k4yK0xxt3xW+6Exqp9n9bydiy tcSAw/TahjW6yrA+6JhSBv1v2tIm+itQc073zjSX8OFL51qQVzRFr7H2UQG33lw2QrvHRXqD Ot7ViKam7v0Ho9wEWiQOOZlHItOOXFphWb2yq3nzrKe45oWoSgkxKb97MVsQ+q2SYjJRBBH4 8qKhphADYxkIP6yut/eaj9ImvRUZZRi0DTc8xfnvHGTjKbJzC2xpFcY0DQbZzuwsIZ8OPJCc LM4S7mT25NE5kUTG/TKQCk922vRdGVMoLA7dIQrgXnRXtyT61sg8PG4wcfOnuWf8577aXP1x 6mzw3/jh3F+oSBHb/GcLC7mvWreJifUL2gEdssGfXhGWBo6zLS3qhgtwjay0Jl+kza1lo+Cv BB2T79D4WGdDuVa4eOrQ02TxqGN7G0Biz5ZLRSFzQSQwLn8fbwARAQABzSBWbGFzdGltaWwg QmFia2EgPHZiYWJrYUBzdXNlLmN6PsLBlAQTAQoAPgIbAwULCQgHAwUVCgkICwUWAgMBAAIe AQIXgBYhBKlA1DSZLC6OmRA9UCJPp+fMgqZkBQJkBREIBQkRadznAAoJECJPp+fMgqZkNxIQ ALZRqwdUGzqL2aeSavbum/VF/+td+nZfuH0xeWiO2w8mG0+nPd5j9ujYeHcUP1edE7uQrjOC Gs9sm8+W1xYnbClMJTsXiAV88D2btFUdU1mCXURAL9wWZ8Jsmz5ZH2V6AUszvNezsS/VIT87 AmTtj31TLDGwdxaZTSYLwAOOOtyqafOEq+gJB30RxTRE3h3G1zpO7OM9K6ysLdAlwAGYWgJJ V4JqGsQ/lyEtxxFpUCjb5Pztp7cQxhlkil0oBYHkudiG8j1U3DG8iC6rnB4yJaLphKx57NuQ PIY0Bccg+r9gIQ4XeSK2PQhdXdy3UWBr913ZQ9AI2usid3s5vabo4iBvpJNFLgUmxFnr73SJ KsRh/2OBsg1XXF/wRQGBO9vRuJUAbnaIVcmGOUogdBVS9Sun/Sy4GNA++KtFZK95U7J417/J Hub2xV6Ehc7UGW6fIvIQmzJ3zaTEfuriU1P8ayfddrAgZb25JnOW7L1zdYL8rXiezOyYZ8Fm ZyXjzWdO0RpxcUEp6GsJr11Bc4F3aae9OZtwtLL/jxc7y6pUugB00PodgnQ6CMcfR/HjXlae h2VS3zl9+tQWHu6s1R58t5BuMS2FNA58wU/IazImc/ZQA+slDBfhRDGYlExjg19UXWe/gMcl De3P1kxYPgZdGE2eZpRLIbt+rYnqQKy8UxlszsBNBFsZNTUBCACfQfpSsWJZyi+SHoRdVyX5 J6rI7okc4+b571a7RXD5UhS9dlVRVVAtrU9ANSLqPTQKGVxHrqD39XSw8hxK61pw8p90pg4G /N3iuWEvyt+t0SxDDkClnGsDyRhlUyEWYFEoBrrCizbmahOUwqkJbNMfzj5Y7n7OIJOxNRkB IBOjPdF26dMP69BwePQao1M8Acrrex9sAHYjQGyVmReRjVEtv9iG4DoTsnIR3amKVk6si4Ea X/mrapJqSCcBUVYUFH8M7bsm4CSxier5ofy8jTEa/CfvkqpKThTMCQPNZKY7hke5qEq1CBk2 wxhX48ZrJEFf1v3NuV3OimgsF2odzieNABEBAAHCwXwEGAEKACYCGwwWIQSpQNQ0mSwujpkQ PVAiT6fnzIKmZAUCZAUSmwUJDK5EZgAKCRAiT6fnzIKmZOJGEACOKABgo9wJXsbWhGWYO7mD 8R8mUyJHqbvaz+yTLnvRwfe/VwafFfDMx5GYVYzMY9TWpA8psFTKTUIIQmx2scYsRBUwm5VI EurRWKqENcDRjyo+ol59j0FViYysjQQeobXBDDE31t5SBg++veI6tXfpco/UiKEsDswL1WAr tEAZaruo7254TyH+gydURl2wJuzo/aZ7Y7PpqaODbYv727Dvm5eX64HCyyAH0s6sOCyGF5/p eIhrOn24oBf67KtdAN3H9JoFNUVTYJc1VJU3R1JtVdgwEdr+NEciEfYl0O19VpLE/PZxP4wX PWnhf5WjdoNI1Xec+RcJ5p/pSel0jnvBX8L2cmniYnmI883NhtGZsEWj++wyKiS4NranDFlA HdDM3b4lUth1pTtABKQ1YuTvehj7EfoWD3bv9kuGZGPrAeFNiHPdOT7DaXKeHpW9homgtBxj 8aX/UkSvEGJKUEbFL9cVa5tzyialGkSiZJNkWgeHe+jEcfRT6pJZOJidSCdzvJpbdJmm+eED w9XOLH1IIWh7RURU7G1iOfEfmImFeC3cbbS73LQEFGe1urxvIH5K/7vX+FkNcr9ujwWuPE9b 1C2o4i/yZPLXIVy387EjA6GZMqvQUFuSTs/GeBcv0NjIQi8867H3uLjz+mQy63fAitsDwLmR EP+ylKVEKb0Q2A== In-Reply-To: <20250226024126.3718-1-zhongjinji@honor.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: B56DB40015 X-Stat-Signature: oudpedpjnimrt577qfifdukr8sbn11cb X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1740740518-555747 X-HE-Meta: U2FsdGVkX1/CnIh9gUUeLj93TNVtVjKPV6cXILvYvY2gHj2hPpZww0iudstDuXL1kA3AmJqmMlsT6C67tTVsVhsejMBrjKKDGcDRaG3XIlp59vwWKritCj/QBedwaz/+1iWTsmNBHhVEauLzHAoRlonomg1mx1kS4xP86yLlBZnneR4DCmwHHVk+HYhX0KSECY6C8F2dZhUm+CN/eNJ36S0r8UtEKZtg5NxlDYJZbb+zfVHFey31a7lwntA43y2i/vOdliQwt71XtnKy+38eCmcvq+HMLQbkE6VJHUj3RL15bF227wSmW0YXHuROJc91wb3zTu+zetIx3z/5Eg+P976Wb4jP1usnO82NRK1kFVOyqAZshoVJcbYjKWpQmtal7dnPS84cD1xF41DfZh8M/88E+Vpa+6RRqgRoZB0o6GJG4G0uIzge3EVv33xq4SahQW/cIPrO5IrfziolJ8MsxoOkhFrHDO7NQUwcvQP0GoAuPqmZfSBl1Zi3vx3EBVFxnymqfr8DwG+g06l1fqBeoMdHvwE0Kvp4WR2yMu8jqYtTmQFBWekV69KFC5BkSkrN2RoctsfQ8yXPDlRz/Ofwb/VjGe+9lFlCMeByVEnFbGZrUIEu0kAek1qlX9KDnYcEfDr9fnmKjCqOGnxrP8zZVnzSVcqzju2h3oK09F1UN+7B9mFWH5341dCWejyWv9r2EtGav9P/viQe6RRfcEnZxGxAzLnLj7Lotu5Hbg1YrMsb2kxubJ8bTYMgM/ZOZ8Oc1Y79FiRUI338eu4gjLWhUNQJFfChJ/Ss2Pzx96CBmWi0Y9o3jBn8VoicSMJccXXwXXXXXhdB8lMxbXaNWvbRQgZ74qquDYF18HbtZzkY1AZ4QS4gD5fwrKHFcUc8bfvBIx1/UW1ustorn1xOqN/cNfbxuXFU1TK9+8jTSZpfgdMVLTteALoulZGVpVpzXo7P41wBoTfQI8X75Ga2FBW FK7akyTf oH5tK8Yzp7IEnitaxShFiUtiw6Hf5iv028V/HoQs1Kf+BQNuVXmEf4psoUWGMaqqs0XTANWTFMWFxgooWUyGlPuun/BTgaUwZNXBPYO/h0/8vsgLewrz314Xbrmz8sQz+HpvDLJIEFUAf9AopgGv4eJsvQsCZRHj1rXDXrI8oOL1Q4/An0mVwPkX8tAhjcGinPvwyrAzLnEd8UH99gDrT4qQ1A8VyAarU9ilLcJCIlfgtFKDq8V5xBty8f6mQe0MO5raNQrttHXIdsqCN+9RRJRTZz8l5GNWIm7Xq1//1PVz4DT6PG0yd21XBy941zSdcP++6MDHLYVq86j4y7VXlAcVm4lR0v1cLazCip7JHgmuEX+/8MZUGhixDX9FdswjP8P5g4ihUkDtWqGl00NVw79fMp0B01A4EmNXnuIR1SC9X3JeDfLuIgqbDihuZQn+WhJmd 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: List-Subscribe: List-Unsubscribe: +Cc Mel, Johannes and Brendan, please keep on future submissions On 2/26/25 03:41, zhongjinji@honor.com wrote: > From: zhongjinji > > In the past, nr_reserved_highatomic was considered to be part of > unusable_free when there was no ALLOC_RESERVES flag. To prevent > unusable_free from being too large, it is reasonable to set a > fixed maximum highatomic value. > > Even if the maximum number of highatomic pageblocks is set to be larger, > unusable_free may not increase, since Yu Zhao provided the modification > about nr_free_highatomic in > https://lore.kernel.org/all/20241028182653.3420139-1-yuzhao@google.com/T/#u I think I raised in discussing that patch the fact that unreserve_highatomic_pageblock() is flawed in that it will only find a highatomic block to unreserve if it has some free pages as it searches via freelist. So if the existing reserve becomes fully used up, it's dead weight, unless the highatomic allocations are shortlived. It could make sense to remove the HIGHATOMIC marking so other, more free blocks might be reserved instead. I fear if this approach isn't just working around that limitation. > More highatomic pageblocks are beneficial for the successful allocation > of high-order page, which is helpful in some devices. Therefore, use Can you elaborate what is it helpful with? And what kind of values you expect to be using? Do you find that your existing HIGHATOMIC blocks are fully depleted as I speculate above? Are your highatomic allocations short or long lived? Maybe simply at this point nr_free_highatomic would be a better metric than nr_reserved_highatomic to decide if we should reserve another pageblock? The counter didn't exist when highatomic reserves were introduced. But maybe also some mechanism (compaction maybe?) could also be looking for highatomic blocks that are fully used and unreserve them? > highatomic_reserve_ratio to adjust the maximum number of highatomic > pageblocks. > > Signed-off-by: zhongjinji Minimally this needs to be documented in e.g. Documentation/admin-guide/sysctl/vm.rst, it's not obvious that the value is divided by 1000 and not 100 for example. > --- > mm/page_alloc.c | 11 ++++++++++- > 1 file changed, 10 insertions(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 579789600a3c..dbdce6a0f694 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -273,6 +273,7 @@ int min_free_kbytes = 1024; > int user_min_free_kbytes = -1; > static int watermark_boost_factor __read_mostly = 15000; > static int watermark_scale_factor = 10; > +static int highatomic_reserve_ratio = 10; > > /* movable_zone is the "real" zone pages in ZONE_MOVABLE are taken from */ > int movable_zone; > @@ -2046,7 +2047,8 @@ static void reserve_highatomic_pageblock(struct page *page, int order, > */ > if ((zone_managed_pages(zone) / 100) < pageblock_nr_pages) > return; > - max_managed = ALIGN((zone_managed_pages(zone) / 100), pageblock_nr_pages); > + max_managed = ALIGN((zone_managed_pages(zone) * highatomic_reserve_ratio / 1000), > + pageblock_nr_pages); > if (zone->nr_reserved_highatomic >= max_managed) > return; > > @@ -6199,6 +6201,13 @@ static const struct ctl_table page_alloc_sysctl_table[] = { > .mode = 0644, > .proc_handler = percpu_pagelist_high_fraction_sysctl_handler, > .extra1 = SYSCTL_ZERO, > + }, > + .procname = "highatomic_reserve_ratio", > + .data = &highatomic_reserve_ratio, > + .maxlen = sizeof(highatomic_reserve_ratio), > + .mode = 0644, > + .proc_handler = proc_dointvec_minmax, > + .extra1 = SYSCTL_ZERO, > }, > { > .procname = "lowmem_reserve_ratio",