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 A40F5E64AB1 for ; Tue, 3 Dec 2024 14:24:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19CCC6B0096; Tue, 3 Dec 2024 09:24:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 14D136B00A4; Tue, 3 Dec 2024 09:24:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F08366B00A6; Tue, 3 Dec 2024 09:24:04 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id D2F066B0096 for ; Tue, 3 Dec 2024 09:24:04 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 85D0F120928 for ; Tue, 3 Dec 2024 14:24:04 +0000 (UTC) X-FDA: 82853866662.07.1C86907 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf04.hostedemail.com (Postfix) with ESMTP id 9EEA540019 for ; Tue, 3 Dec 2024 14:23:47 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=RjvkpFfO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=hmGbxWSw; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=RjvkpFfO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=hmGbxWSw; spf=pass (imf04.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1733235833; 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=FHkL2249fzmDatUIGMAizAA5fswy2PLAfdBQjzG7uO8=; b=OIjQNGkrimicOxvwpxQG5mNqC6yB3HqlNbg4CKBIeW3vNu3zthdO5wa7yQN1Z3SMHVonNq ZdB6kp0yqkX/Pnp1tq9pAukelEQW0xnEFjIG5gzZ/E/uoselzYlz0zwu5UTsPIPmWazcuw p9A0cr7X+2nU9ioXtNlltRc/aM52fEc= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=RjvkpFfO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=hmGbxWSw; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=RjvkpFfO; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=hmGbxWSw; spf=pass (imf04.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1733235833; a=rsa-sha256; cv=none; b=uhxuiW43xTm/U4RFS6Jjw8iNU69mPkFPiBwEpulbQxd+rliQLtBLw24UAsLhoZEvZz9hyC T/edQgg3G3fUgMAZYR80juOa+dXMqZd5GCbByq1Bt5+Wf/VOJGIEnFwx5AZbAosaPojYPn kJvywPZbsicUezTp78fRnT0zSu1bfmY= 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 7F91121160; Tue, 3 Dec 2024 14:24:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1733235840; 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=FHkL2249fzmDatUIGMAizAA5fswy2PLAfdBQjzG7uO8=; b=RjvkpFfO3E7hnN6rvlmAzMsOvBXl09qj8efilOvlxHkOVkTA0SJZ3+JYT7mCXE5MDbfowe p6dlF0H3mILWSVWC0/u9Kgzz/SFTK7Lb2Uoj3mI5STiJ/nEbFPdjJst57WLnJBiyFGZVwi JN6D48OVP9X2r8bRpwwoVbR4xlef8tU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1733235840; 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=FHkL2249fzmDatUIGMAizAA5fswy2PLAfdBQjzG7uO8=; b=hmGbxWSwEOOwU1nWFCoxCEbFqSGBCLEjdWIRAWilRw2wt1LmF15sBfswWolY7dTVhygaZO xvzrynMrUJrsJPBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1733235840; 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=FHkL2249fzmDatUIGMAizAA5fswy2PLAfdBQjzG7uO8=; b=RjvkpFfO3E7hnN6rvlmAzMsOvBXl09qj8efilOvlxHkOVkTA0SJZ3+JYT7mCXE5MDbfowe p6dlF0H3mILWSVWC0/u9Kgzz/SFTK7Lb2Uoj3mI5STiJ/nEbFPdjJst57WLnJBiyFGZVwi JN6D48OVP9X2r8bRpwwoVbR4xlef8tU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1733235840; 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=FHkL2249fzmDatUIGMAizAA5fswy2PLAfdBQjzG7uO8=; b=hmGbxWSwEOOwU1nWFCoxCEbFqSGBCLEjdWIRAWilRw2wt1LmF15sBfswWolY7dTVhygaZO xvzrynMrUJrsJPBw== 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 605B0139C2; Tue, 3 Dec 2024 14:24:00 +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 jA2AFoAUT2doMgAAD6G6ig (envelope-from ); Tue, 03 Dec 2024 14:24:00 +0000 Message-ID: <04c1d28e-bbea-4499-9a6d-770f9ca53ba9@suse.cz> Date: Tue, 3 Dec 2024 15:24:00 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH RESEND v2 4/6] mm/page_alloc: sort out the alloc_contig_range() gfp flags mess Content-Language: en-US To: David Hildenbrand , linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, Andrew Morton , Oscar Salvador , Zi Yan , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Naveen N Rao , Madhavan Srinivasan References: <20241203094732.200195-1-david@redhat.com> <20241203094732.200195-5-david@redhat.com> <96c92857-4850-4f85-9474-ac193c5ea48c@redhat.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: <96c92857-4850-4f85-9474-ac193c5ea48c@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam05 X-Stat-Signature: tfx96mcguuh5j9me5rwrk63j7jpcg9ru X-Rspamd-Queue-Id: 9EEA540019 X-Rspam-User: X-HE-Tag: 1733235827-67914 X-HE-Meta: U2FsdGVkX18qElmzy1Eh6613JvXEGVc4w34hDHoBRQD3m+B+LSuk81wGShqqFlt+G7DVfOyuTsfip3ZRhJed/NwVlJ7SxzdV8W40VywCk6fx86NFFmRH6D8DW+9CCXdsN2Z6xk4ZNKLSARvXrfpOMnk/jj1+tS+GLYj6LJFUmFxVJketB3UNKxQTRJPgYZKZxUMmk9KxtdCnCXLjXTd3cTAYY6bVw0vtVzLG7aisUSweeqcJlrJNzmEhjpYCDZmwvN3SnKsqSVPl5iShyvt6MjTE7zucJFDWkoiID+8awTCunACIQhdl+zZy8VWTysZBs2OVuYLD9bBB4d/RGlBmw8+QeJeXmBXJ8p3HhqcffBvkIh+LpJfdq+ozs0FQHh7EkIbZ1ddIYVDRndBTk9tiHGbZ32uoBa+6reKDB1hkI+9lRgr/MbVUzqj674b4BhJfv4d9Lfe5CU7yxkIbD/GtJn1+UZ7xpGBsJuplvBO7n42aYzcqOvlRYpLOF2sihFuPn8zhDpRWMhyST9R+/6DCejrdfnBGNft5Ug52H2WwwsUH6efHJEAyg1xS911HZklM3jPuMnDBDZFeiUOcWr+afvsZwRd7Qe8nATcN++luqTZh32JG78X19mt5SaGqnSfknYx+VEPqjuv0I6AaluPaY5ad31YGcXEfJqqtTzBgEovnu9pW6ykU5AnsrvqIoDVVPim3U3Gqive8DuYLNB1kR2btKOsLsvCp267qG29WI1uJVBBkZrvPJJ5bn4xmpPWJkwayyA4WRolrc3+CGDLVqHRHgxBjgJp9Z4PaYDRJdawaii9cn2Ra2Jnb4BT+x/ZmnqW5OBmqFF3aE2cjo8OI3639uNUc38IVakZ+xfdiQRoSz1g2J/N+HrM0LkH3YTO3xaWhou3EDs/bNaIf+KXXsIyve+3JV4D5UizOexTFwYCfM9TVMbNv8ZjgXaedRX9fYoqbml9s1AtwF6b0e7M PUH04PLx gmJTON2TV9shENCHr34Xcn9PQc/o0c9aQNJkEY8Pu0lyiyDYFcyfhynFS1M6eP3X/+caAeIMemgTAUv4kXdjgCbuVvQIOOaSf1thJ8e3vLpmAWiM8vF2dQzDZ2d2e/bCiiNXQVDzLO8VYtx6u8rAlbe78Wsem8dHHNrdeCGmC0Ax0GAst35vQlNJnv9Tit5X38EM01vspAsde+yf2U3nNNJSBoZCkVsPrvOC5gxB6qnsyBkQ9Mar+zvP5etDWMv2FtNftOFuFislG7OxR9sTY2DjSyrPOnvb/6FQI7vRsigRNvSma4EcEp9Q11Hg5dElmFY06o+s+i0igJSzWZYhlh9FRbxZyHEffZfVSpMWOc7zeNTHYcdps4LzIaq2pXsx1SjQz 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: On 12/3/24 15:12, David Hildenbrand wrote: > On 03.12.24 14:55, Vlastimil Babka wrote: >> On 12/3/24 10:47, David Hildenbrand wrote: >>> It's all a bit complicated for alloc_contig_range(). For example, we don't >>> support many flags, so let's start bailing out on unsupported >>> ones -- ignoring the placement hints, as we are already given the range >>> to allocate. >>> >>> While we currently set cc.gfp_mask, in __alloc_contig_migrate_range() we >>> simply create yet another GFP mask whereby we ignore the reclaim flags >>> specify by the caller. That looks very inconsistent. >>> >>> Let's clean it up, constructing the gfp flags used for >>> compaction/migration exactly once. Update the documentation of the >>> gfp_mask parameter for alloc_contig_range() and alloc_contig_pages(). >>> >>> Acked-by: Zi Yan >>> Signed-off-by: David Hildenbrand >> >> Reviewed-by: Vlastimil Babka >> >>> + /* >>> + * Flags to control page compaction/migration/reclaim, to free up our >>> + * page range. Migratable pages are movable, __GFP_MOVABLE is implied >>> + * for them. >>> + * >>> + * Traditionally we always had __GFP_HARDWALL|__GFP_RETRY_MAYFAIL set, >>> + * keep doing that to not degrade callers. >>> + */ >> >> Wonder if we could revisit that eventually. Why limit migration targets by >> cpuset via __GFP_HARDWALL if we were not called with __GFP_HARDWALL? And why >> weaken the attempts with __GFP_RETRY_MAYFAIL if we didn't specify it? > > See below. > >> >> Unless I'm missing something, cc->gfp is only checked for __GFP_FS and >> __GFP_NOWARN in few places, so it's mostly migration_target_control the >> callers could meaningfully influence. > > Note the fist change in the file, where we now use the mask instead of coming up > with another one out of the blue. :) I know. What I wanted to say - cc->gfp is on its own only checked in few places, but now since we also translate it to migration_target_control's gfp_mask, it's mostly that part the caller might influence with the passed flags. But we still impose own additions to it, limiting that influence. > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index ce7589a4ec01..54594cc4f650 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -6294,7 +6294,7 @@ static int __alloc_contig_migrate_range(struct compact_control *cc, > int ret = 0; > struct migration_target_control mtc = { > .nid = zone_to_nid(cc->zone), > - .gfp_mask = GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL, > + .gfp_mask = cc->gfp_mask, > .reason = MR_CONTIG_RANGE, > }; > > GFP_USER contains __GFP_HARDWALL. I am not sure if that matters here, but Yeah wonder if GFP_USER was used specifically for that part, or just randomly :) > likely the thing we are assuming here is that we are migrating a page, and > usually, these are user allocation (except maybe balloon and some other non-lru > movable things). Yeah and user allocations obey cpuset and mempolicies etc. But these are likely somebody elses allocations that were done according to their policies. With our migration we might be actually violating those, which probably can't be helped (is at least migration within the same node preferred? hmm). But it doesn't seem to me that our caller's restrictions (if those exist, would be enforced by __GFP_HARDWALL) are that relevant for somebody else's pages? > The __GFP_RETRY_MAYFAIL should be moved to relevant callers a some point, > __GFP_HARDWALL, I really don't know ... > > Thanks! >