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 705DBE64AAA for ; Tue, 3 Dec 2024 13:55:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B769C6B0093; Tue, 3 Dec 2024 08:55:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B26526B0095; Tue, 3 Dec 2024 08:55:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9EDB86B0096; Tue, 3 Dec 2024 08:55:58 -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 7BB216B0093 for ; Tue, 3 Dec 2024 08:55:58 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2B27D12097C for ; Tue, 3 Dec 2024 13:55:58 +0000 (UTC) X-FDA: 82853795766.19.80D3258 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf17.hostedemail.com (Postfix) with ESMTP id C277040017 for ; Tue, 3 Dec 2024 13:55:45 +0000 (UTC) Authentication-Results: imf17.hostedemail.com; dkim=none; spf=pass (imf17.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=1733234147; 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=4KynxMQIIsg9lKBo+Malf4czBIJ4XCORrknIGenaWYs=; b=TLu42jV+3VjgA62h4fdBG+/Ov7YQKz1Rb2W6y7tiFOj+Vggd3Um8TiJmZH8pKdprKrFODh 3+u+j6oB5LwTsrdStgVeO59VlcO2fCsqf0HaQErhVaRblobESbxSZQsFxi2WF5Xf5unywF JqLIiXKqaASULnFM58tDrid7sOOKkUk= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=none; spf=pass (imf17.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=1733234147; a=rsa-sha256; cv=none; b=Jt4Ev1nguMw/P+PwfE1MFF/8Pg6tbwuehV180GBmBDbIW4q0klPzTz32sURbR1fo1+mdor xfDwX1pL/R106hS1ddKpvHPiVAQCrxVNzu3wUAGX9QQA3SBAJjnSmUtf0cKfqyLeXT6/id nwrCaFxC4Xo9LzB2WsJ23ULG9mXiRic= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104: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 3C7DE21166; Tue, 3 Dec 2024 13:55:54 +0000 (UTC) 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 206F513A15; Tue, 3 Dec 2024 13:55:54 +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 +NefB+oNT2dGKQAAD6G6ig (envelope-from ); Tue, 03 Dec 2024 13:55:54 +0000 Message-ID: Date: Tue, 3 Dec 2024 14:55:53 +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> From: Vlastimil Babka In-Reply-To: <20241203094732.200195-5-david@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Action: no action X-Rspamd-Server: rspam05 X-Stat-Signature: 4nedphnqndhy7kynmspieamgegu31b5k X-Rspamd-Queue-Id: C277040017 X-Rspam-User: X-HE-Tag: 1733234145-148268 X-HE-Meta: U2FsdGVkX1+MQUnsPn3+wSN3PEh/6fW3+iD5Lv+b9zHkDmDU+L46qi43vCaATq4zyPqMRyRoGBVbqygUFTOgcT7tkHsFZnfPcaiwy0fAHBqMVzrUFOVBsEyHLsuZC2ux8zMtbs9X3Rr556DUUUeZyr3KPOtayp5mxI+Ww03FdkAWHHKSQTURbBWGUY1Js9xdDpHERjseaBaGhR9Gg+jsr3OeI28BuxJ4+TYyQpHLPN+zGll9klwmqDULlpuYkYvwh92LdenSxRt0J07NziXpliLOri0Bi6z1yX9BSQY3kHsvOCFYHMCoKCwZbsAwVigzslVAanuQlIZyPD5U2oTesDLpHanAUYoJe3hLpsynnPWC2R2xLL+i6/IJa08UHrqjsM3ynK4jbaUWzF3ZQaRWfTzcv9tBFi1BHApbAnYhjhcJUtTFOz85ojuut+6jPuBmiv/t3UWHvSWr8uIbNouCkZOBm98DdpTSKDy5JYGuiOCLsGy3WxUAy2CF6XumfTDpZDULTmTGMnpgz6HJ2JwgHW8aUHCRvhF/3lb9oR2bOcp2a0s6DqhdSBfH69XF8pyEi6qN3EVMKKxab6FhZtPpF6ZPU7fYkIrXolphEH8AXWGEaVx2pyqQ9nIVsNNBwQXiFwHD2dyvf3jcii1N5oAssmQgezPlAkSIB/kMdtaHkz2953VbsDyowFfSrt2bHBahlIXaBBeGckTEbpUeNFevcB9Qqgb6edOz+CUKB9vaADpYvzDjS85aRM+6onGkvjIV3OJ747jOBKhrk0rKmaKGZSHzYnBbWBP+syl5l22vFbrKuXWj36p3oxmbIeMXYEtXg6zQcF9laYXlcuyeqTQg1Xt49+54d6iIWsDAK55XjeMl1USrDwttzqXkGR03fwcnezLYfsF5wzqUOmXxkB6jkBEBw/Rj/B0J9/ssb8xUTk6kDWUJYgyGVoRXhtzu+b7aIr+QObhcOJPtF7Vr+3A umKUd3tA sJN4MAro5f2tVZUTGL0W57T+NvMbxckEerSw70RsO/fUf/xQB7H5CcqaAc60i6oMMyiX8NS5l9FVlmsFvd7/FIjiINxd8sjApeLptnpJOKBJ2U3KVDZAkkgwhX2NgdxHnO2lHZ2F3xij2c5yXhb2XKpPoYJxE85etvT/Ox0LumZgpqkgWUlL13ztiUpl1odBLdgEAWapd1o0oL9hIYNl+7u5SQpz+wcpt00FLnNpOBm+IOFs4Zl1mSkHPRA== 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 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? 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. > + *gfp_cc_mask = (gfp_mask & (reclaim_mask | cc_action_mask)) | > + __GFP_HARDWALL | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL; > + return 0; > +} > + > /** > * alloc_contig_range() -- tries to allocate given range of pages > * @start: start PFN to allocate > @@ -6398,7 +6431,9 @@ static void split_free_pages(struct list_head *list) > * #MIGRATE_MOVABLE or #MIGRATE_CMA). All pageblocks > * in range must have the same migratetype and it must > * be either of the two. > - * @gfp_mask: GFP mask to use during compaction > + * @gfp_mask: GFP mask. Node/zone/placement hints are ignored; only some > + * action and reclaim modifiers are supported. Reclaim modifiers > + * control allocation behavior during compaction/migration/reclaim. > * > * The PFN range does not have to be pageblock aligned. The PFN range must > * belong to a single zone. > @@ -6424,11 +6459,14 @@ int alloc_contig_range_noprof(unsigned long start, unsigned long end, > .mode = MIGRATE_SYNC, > .ignore_skip_hint = true, > .no_set_skip_hint = true, > - .gfp_mask = current_gfp_context(gfp_mask), > .alloc_contig = true, > }; > INIT_LIST_HEAD(&cc.migratepages); > > + gfp_mask = current_gfp_context(gfp_mask); > + if (__alloc_contig_verify_gfp_mask(gfp_mask, (gfp_t *)&cc.gfp_mask)) > + return -EINVAL; > + > /* > * What we do here is we mark all pageblocks in range as > * MIGRATE_ISOLATE. Because pageblock and max order pages may > @@ -6571,7 +6609,9 @@ static bool zone_spans_last_pfn(const struct zone *zone, > /** > * alloc_contig_pages() -- tries to find and allocate contiguous range of pages > * @nr_pages: Number of contiguous pages to allocate > - * @gfp_mask: GFP mask to limit search and used during compaction > + * @gfp_mask: GFP mask. Node/zone/placement hints limit the search; only some > + * action and reclaim modifiers are supported. Reclaim modifiers > + * control allocation behavior during compaction/migration/reclaim. > * @nid: Target node > * @nodemask: Mask for other possible nodes > *