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 50959C02180 for ; Wed, 15 Jan 2025 09:57:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D776B280003; Wed, 15 Jan 2025 04:57:01 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D283A280001; Wed, 15 Jan 2025 04:57:01 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BA163280003; Wed, 15 Jan 2025 04:57: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 9BDAB280001 for ; Wed, 15 Jan 2025 04:57:01 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 635E5B0443 for ; Wed, 15 Jan 2025 09:57:01 +0000 (UTC) X-FDA: 83009232642.19.1B80108 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf26.hostedemail.com (Postfix) with ESMTP id EDC3614000C for ; Wed, 15 Jan 2025 09:56:58 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=bvviPCv5; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6TWwZSgW; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=bIZdsLpU; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wjslElvP; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 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=1736935019; 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=haewsQLgQKz5N7NO6mMml/LVTp2fuEGjAtUdpsbOnD0=; b=0ojAt1eVcwsnK4s0I/06wloWfM6g5knpySShTrR8jMfks5xAGGcz32EzR/5M+O66XyRCqg bj69mVYaJ+7WpusCHw2XMw2txIsfQzVlqPdxWRpRyM2+T0l2sQ6oJdWFtHImMLLcb67Ksw lPqfyU+0ZR1NpGBbMqwrX8gHYn3HLRk= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736935019; a=rsa-sha256; cv=none; b=dxahinQjkQ2Ov8mMLke/jEUa8knSiqstKLXbX1KHzcKCxsB+YuLUZQdb5PSPStKZAnQ47Q 0vFTmwFURhOLx+WFUMvQb2/bZ6r5Cqpbt4/Yf6zKbk80Y6gvkJPiu2NReIC8fs2qpMxli1 85e0M9EA7hvAm9XyJm+wpcXiqaCfwjo= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=bvviPCv5; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6TWwZSgW; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=bIZdsLpU; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=wjslElvP; spf=pass (imf26.hostedemail.com: domain of vbabka@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=vbabka@suse.cz; dmarc=none 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-out2.suse.de (Postfix) with ESMTPS id E40021F444; Wed, 15 Jan 2025 09:56:56 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1736935017; 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=haewsQLgQKz5N7NO6mMml/LVTp2fuEGjAtUdpsbOnD0=; b=bvviPCv504uWdbh13O13ARSY686ZJz8ujWZoaW4olDqIA9mGjRyZChImDI+TPgCzR6pJRA 80hU8Nat4FT/DlbYGGWHkXiao9uet60QzgOsGxkoBvj74/vGAwkdFlm++YR71y3qImAdyK CtywmM3gX4VLxd26eMLLFZ99WKGZzA4= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1736935017; 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=haewsQLgQKz5N7NO6mMml/LVTp2fuEGjAtUdpsbOnD0=; b=6TWwZSgWm7fvwRn5fib2/cGVRfdRo4Ropq7kfId7m4k/7A4dlcpWLeUwtXaokGI1zkrSw1 2PETRPNRN/M5TkDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1736935016; 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=haewsQLgQKz5N7NO6mMml/LVTp2fuEGjAtUdpsbOnD0=; b=bIZdsLpUnaEUowOnUvbB6KyGphw+TL0AQB+DZexe6LKI1FVVdj9BRS5ka8ewiuJ6GMiXF6 tkN9BudrlLqsYmbze57VoUuZ/t1CIlyLOxcvrNUEeSCaQoz8l7O4EOHzE/6S0QA78bGET/ QHf223X7AqHkqcmY96jZ8ZL6l0o+yps= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1736935016; 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=haewsQLgQKz5N7NO6mMml/LVTp2fuEGjAtUdpsbOnD0=; b=wjslElvPXP7nHXkif55Z84ouACbiai8BIhSFxbDOfq3lxXAonTqgupKY60c7WnFlggvMAI RlyXu709642tUmDg== 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 BA76A139CB; Wed, 15 Jan 2025 09:56: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 4/cuLWiGh2cPIAAAD6G6ig (envelope-from ); Wed, 15 Jan 2025 09:56:56 +0000 Message-ID: Date: Wed, 15 Jan 2025 10:56:56 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: compaction: use the actual allocation context to determine the watermarks for costly order during async memory compaction To: yangge1116@126.com, akpm@linux-foundation.org Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, 21cnbao@gmail.com, david@redhat.com, baolin.wang@linux.alibaba.com, hannes@cmpxchg.org, liuzixing@hygon.cn References: <1736929894-19228-1-git-send-email-yangge1116@126.com> Content-Language: en-US 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: <1736929894-19228-1-git-send-email-yangge1116@126.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: EDC3614000C X-Stat-Signature: y1d4ps4s4t9kcknhh3ppbwgrgfzx5eif X-Rspam-User: X-HE-Tag: 1736935018-44654 X-HE-Meta: U2FsdGVkX1/RboSHOQNHAMYuF1+WMneqF2i1ifpPQV3f8gp+nh0J76f8A/LwUGmX3mknmjqg7uFCA57MNw5QkDDBpN9YqqKRMH5d286i6O8qJ7JElVY52U31jTlMabpTGHtEK7T74f5cx8xP6ru/kpufszaU5nkSuhuM5jhu11aiYcssRLLgbxQK5Gjxgc3AHuYXaZAqhBPEHrOvhyiE9+DhPkDZOHphF9GxkJ8zMnyUS04+0R+9rn2Xx3yW0tRdypbv7rYbmXewTEfRiVLXp7O9pP9L/MNzMN/1WPCFgJTa4ObsSReA1VC50yOh5XvWv9OedBUCnVzACBubLWCz7BS4r31x+HFd4dC+2YuKEYox48DExjVFWGw8JkRCwUp+PgaJcsrbOkEXZUDHVukn4Yrcsgom4fis3gwjRcVjvTk5hXxCrV7IF56oBBwcR4sFLrXtyPywOgRmjBN/LQZ+bbK1Bo+PeeV7tZ2aToaLtTCzEKYKJhr3mkVLsJZES6JQ9Y8r6WO64HtZW93TVFU338a91r1f2UXG9ZBvmETbz3E6caDVsG2c38ksBLALN9KuKMJGGLHseJUh8dlOoG1/j3WuLNyCE3hhcESM+QXFz7q8b7NCO22UaqX/LLOp7RlhjwsHaENZqfcq0cBf02gr+JKe2A0mmjnSRISzYYXT9KjdibyEjfH9KpTMFrdIWeuN6HI9+/hZkEefNrXqi5Jp0FrVeeAdFD1Qz6pmAUnXWTRZsXnp2Yrn2F/K7/GRoilS8LMhMyx8cWe1i8jz1Y4chrQu6ORmy4V1QNkTT0wQ66CtpZ3j+2wcghGuaYrQWFWdTX40A2TQbdw2Mq8LAwhMjaUIqgnCxKsyyBWc7ToSReyKqUehYVkCr2F8qVA4gh3qhYo815E5hhzKxB0Ju+cJ/utq8qCNIY1TGj+zvdAPiYS/O15mpWS6+iNO48pUpIWd8UCFO97eaWbod584NvD mIrt8S3S FbKel1U5NvSP77PHxpX7DEn4RoIeQ0N771JxORp7SE+lebwoz10LfatTjgvltAH3Hw7XiGpfv6H8st5kzpLoNcnWZRtH6qbxkm1CUPQwPXbZj9oNPTJMbmulBbgye90+2/wRyk4pd6lSdXplI20uuD6TVZ8La3cMSRG8KFpHlEAKqqFf/peeYaHLxFBJrxYPf6k11+ydLpqgPJZjgJSCgAWv+w1OAZiBcLe3muHlB1etXQwwY89cQyTvqkFbBXtR/LgOmifgKOo9JSJCf8BpSYJMI0/N55OvNZr7ZI6/e/0q23SGTfm9MSCApwvZA5OUYqhVjVFH5l2NPPlOtEZ4XhjRvfIhL5lPbdogL+/ayMcKCs5JuJBplFHHmctv7xkZEesRq6VAFGLRRcElKCuChB1AJPA== 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 1/15/25 09:31, yangge1116@126.com wrote: > From: yangge > > There are 4 NUMA nodes on my machine, and each NUMA node has 32GB > of memory. I have configured 16GB of CMA memory on each NUMA node, > and starting a 32GB virtual machine with device passthrough is > extremely slow, taking almost an hour. > > Long term GUP cannot allocate memory from CMA area, so a maximum of > 16 GB of no-CMA memory on a NUMA node can be used as virtual machine > memory. There is 16GB of free CMA memory on a NUMA node, which is > sufficient to pass the order-0 watermark check, causing the > __compaction_suitable() function to consistently return true. > > For costly allocations, if the __compaction_suitable() function always > returns true, it causes the __alloc_pages_slowpath() function to fail > to exit at the appropriate point. This prevents timely fallback to > allocating memory on other nodes, ultimately resulting in excessively > long virtual machine startup times. > Call trace: > __alloc_pages_slowpath > if (compact_result == COMPACT_SKIPPED || > compact_result == COMPACT_DEFERRED) > goto nopage; // should exit __alloc_pages_slowpath() from here > > We could use the real unmovable allocation context to have > __zone_watermark_unusable_free() subtract CMA pages, and thus we won't > pass the order-0 check anymore once the non-CMA part is exhausted. There > is some risk that in some different scenario the compaction could in > fact migrate pages from the exhausted non-CMA part of the zone to the > CMA part and succeed, and we'll skip it instead. But only __GFP_NORETRY > allocations should be affected in the immediate "goto nopage" when > compaction is skipped, others will attempt with DEF_COMPACT_PRIORITY > anyway and won't fail without trying to compact-migrate the non-CMA > pageblocks into CMA pageblocks first, so it should be fine. > > After this fix, it only takes a few tens of seconds to start a 32GB > virtual machine with device passthrough functionality. So did you verify it works? I just realized there might be still cases it won't help. There might be enough free order-0 pages in the non-CMA pageblocks (so the additional check will not stop us) but fragmented and impossible to compact due to unmovable pages. Then we won't avoid your issue, right? > Link: https://lore.kernel.org/lkml/1736335854-548-1-git-send-email-yangge1116@126.com/ > Signed-off-by: yangge In case it really helps reliably: Acked-by: Vlastimil Babka Some nits below: > --- > mm/compaction.c | 31 +++++++++++++++++++++++++++---- > 1 file changed, 27 insertions(+), 4 deletions(-) > > diff --git a/mm/compaction.c b/mm/compaction.c > index 07bd227..9032bb6 100644 > --- a/mm/compaction.c > +++ b/mm/compaction.c > @@ -2490,7 +2490,8 @@ bool compaction_zonelist_suitable(struct alloc_context *ac, int order, > */ > static enum compact_result > compaction_suit_allocation_order(struct zone *zone, unsigned int order, > - int highest_zoneidx, unsigned int alloc_flags) > + int highest_zoneidx, unsigned int alloc_flags, > + bool async) > { > unsigned long watermark; > > @@ -2499,6 +2500,25 @@ compaction_suit_allocation_order(struct zone *zone, unsigned int order, > alloc_flags)) > return COMPACT_SUCCESS; > > + /* > + * For costly orders, during the async memory compaction process, use the > + * actual allocation context to determine the watermarks. There's some risk > + * that in some different scenario the compaction could in fact migrate > + * pages from the exhausted non-CMA part of the zone to the CMA part and > + * succeed, and we'll skip it instead. But only __GFP_NORETRY allocations > + * should be affected in the immediate "goto nopage" when compaction is > + * skipped, others will attempt with DEF_COMPACT_PRIORITY anyway and won't > + * fail without trying to compact-migrate the non-CMA pageblocks into CMA > + * pageblocks first, so it should be fine. I think it's explaining too much about why not do this than why do this. How about: For unmovable allocations (without ALLOC_CMA), check if there is enough free memory in the non-CMA pageblocks. Otherwise compaction could form the high-order page in CMA pageblocks, which would not help the allocation to succeed. However, limit the check to costly order async compaction (such as opportunistic THP attempts) because there is the possibility that compaction would migrate pages from non-CMA to CMA pageblock. > + */ > + if (order > PAGE_ALLOC_COSTLY_ORDER && async) { We could also check for !(alloc_flags & ALLOC_CMA) here to avoid the watermark check in the normal THP allocation case (not from pinned gup), because then it just repeats the watermark check that was done above. > + watermark = low_wmark_pages(zone) + compact_gap(order); > + if (!__zone_watermark_ok(zone, 0, watermark, highest_zoneidx, > + alloc_flags & ALLOC_CMA, And then here we can just pass 0. > + zone_page_state(zone, NR_FREE_PAGES))) > + return COMPACT_SKIPPED; > + } > + > if (!compaction_suitable(zone, order, highest_zoneidx)) > return COMPACT_SKIPPED; > > @@ -2534,7 +2554,8 @@ compact_zone(struct compact_control *cc, struct capture_control *capc) > if (!is_via_compact_memory(cc->order)) { > ret = compaction_suit_allocation_order(cc->zone, cc->order, > cc->highest_zoneidx, > - cc->alloc_flags); > + cc->alloc_flags, > + cc->mode == MIGRATE_ASYNC); > if (ret != COMPACT_CONTINUE) > return ret; > } > @@ -3037,7 +3058,8 @@ static bool kcompactd_node_suitable(pg_data_t *pgdat) > > ret = compaction_suit_allocation_order(zone, > pgdat->kcompactd_max_order, > - highest_zoneidx, ALLOC_WMARK_MIN); > + highest_zoneidx, ALLOC_WMARK_MIN, > + 0); It's bool, so false instead of 0. > if (ret == COMPACT_CONTINUE) > return true; > } > @@ -3078,7 +3100,8 @@ static void kcompactd_do_work(pg_data_t *pgdat) > continue; > > ret = compaction_suit_allocation_order(zone, > - cc.order, zoneid, ALLOC_WMARK_MIN); > + cc.order, zoneid, ALLOC_WMARK_MIN, > + cc.mode == MIGRATE_ASYNC); We could also just pass false here as kcompactd uses MIGRATE_SYNC_LIGHT and has no real alloc_context. > if (ret != COMPACT_CONTINUE) > continue; >