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 13FC6C36010 for ; Fri, 11 Apr 2025 07:32:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C3396280183; Fri, 11 Apr 2025 03:32:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id BE0D328017D; Fri, 11 Apr 2025 03:32:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AAAD0280183; Fri, 11 Apr 2025 03:32:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 8B7D428017D for ; Fri, 11 Apr 2025 03:32:39 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 13E22C2023 for ; Fri, 11 Apr 2025 07:32:40 +0000 (UTC) X-FDA: 83320945680.17.C797760 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf24.hostedemail.com (Postfix) with ESMTP id BCEAB180005 for ; Fri, 11 Apr 2025 07:32:37 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=btXHBcQv; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=EZdlgi0E; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=btXHBcQv; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=EZdlgi0E; spf=pass (imf24.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=1744356758; 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=dOE6AFasUP2dw9RpzhwVHr8ydKiAOCUzpYc4dztswk0=; b=QUlHv1a3R0CGQpwjJR3J+PcA0qV6gSEj3F02p4KvubMcpcp77fvS1S2YN8aR3aQQa+TRnT VDDSzTLX08+9g4KQvodfXAHlyfRaF+4ETb/G5vJUybQVzQSFqmpvdTfLkyYZ8BVVGyzn6m mw1tfdxTCyKescRAM+vaR8iD8FXADZg= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1744356758; a=rsa-sha256; cv=none; b=AW71pAU+RsfhAOoAVAdKSNlU+LYfJZ0DEmAhYsdukerJFtLnkLyUoWm2BD2IlbwCCVMbPq 6TShPMaHgBI3B3ctv6BReV3xEU6Ho2uzPvEgw6xwGufx1NXPTaEGWu75sh/K9W7rmZYeS8 fyaWDzjGpQ2BAgvEmLhqcP/6tIcnZAk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=btXHBcQv; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=EZdlgi0E; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=btXHBcQv; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=EZdlgi0E; spf=pass (imf24.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 081001F453; Fri, 11 Apr 2025 07:32:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744356756; 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; bh=dOE6AFasUP2dw9RpzhwVHr8ydKiAOCUzpYc4dztswk0=; b=btXHBcQvhNRb7gVWoE8dBdxWm87fKT6W/cGudsdmwXSn32GLz9+TkHHrj6I7e80O/mUVQp jt0TYvT+ORtYFrakdDswq4Vz3WuJ69Kw0N0p7l0MP265PltApicJvKsdQh7/4Op4tAt7YP fO5YSyY259Qcc2lQGHxPS6CXXpV32S0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744356756; 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; bh=dOE6AFasUP2dw9RpzhwVHr8ydKiAOCUzpYc4dztswk0=; b=EZdlgi0E0oAnq3VZqBqrBGuUvXtFd2qi7rrUcs0NhknRjGwI3N8l8CEJgAF4W8a8i4ZQUu 3pD53TiAo5BLVTDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1744356756; 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; bh=dOE6AFasUP2dw9RpzhwVHr8ydKiAOCUzpYc4dztswk0=; b=btXHBcQvhNRb7gVWoE8dBdxWm87fKT6W/cGudsdmwXSn32GLz9+TkHHrj6I7e80O/mUVQp jt0TYvT+ORtYFrakdDswq4Vz3WuJ69Kw0N0p7l0MP265PltApicJvKsdQh7/4Op4tAt7YP fO5YSyY259Qcc2lQGHxPS6CXXpV32S0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1744356756; 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; bh=dOE6AFasUP2dw9RpzhwVHr8ydKiAOCUzpYc4dztswk0=; b=EZdlgi0E0oAnq3VZqBqrBGuUvXtFd2qi7rrUcs0NhknRjGwI3N8l8CEJgAF4W8a8i4ZQUu 3pD53TiAo5BLVTDw== 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 E301B13886; Fri, 11 Apr 2025 07:32:35 +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 S4sJN5PF+GfRAwAAD6G6ig (envelope-from ); Fri, 11 Apr 2025 07:32:35 +0000 Message-ID: Date: Fri, 11 Apr 2025 09:32:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] mm: compaction: push watermark into compaction_suitable() callers Content-Language: en-US To: Johannes Weiner Cc: Andrew Morton , Mel Gorman , Zi Yan , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <20250313210647.1314586-1-hannes@cmpxchg.org> <20250313210647.1314586-2-hannes@cmpxchg.org> <2025de6c-a25b-42f2-8ff2-da2bad0e0aa0@suse.cz> <20250410201718.GA366747@cmpxchg.org> From: Vlastimil Babka In-Reply-To: <20250410201718.GA366747@cmpxchg.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: BCEAB180005 X-Stat-Signature: 984hcwnnrojged894uort86ontnkg8oz X-HE-Tag: 1744356757-91899 X-HE-Meta: U2FsdGVkX1+E4D6ynaL6XEj4sBu3kz0Cioh2FMiplIETzqh7NvC0lfjcCHfnBAXbRWYLGnivIKnxyotvHVfU4+MEHCn2Jak0h5jhWlRnhL4Bw9BK6nbQ9Xcw2JhsCnl7GWPiGEUmztgWHJClhjErm4qJu/Ijed0vODMZ5hjRDSW5JcnBAd/3vLA5QlZYxXlM2Kawdh3Ihlci9GN3THcgMc7x1K5coOdIRKbuJRqPc7bLYs/Wx1wUlH8Tn3U7eF3GrWxvnlvHiO1fIgWDH77JFZAqESxFtvXUXB05AI45PeFcX2wK5E1EUlY3IOmh2OkwPqGqT+7Ekn9C8tdQ+r2QOtGsHR9rH+35wzVsjqdRSBbMBouwBX1bHCOMNpkZqEdoQ/Vu6YhzLkPqd+3p5CthzgTLVst4Ti+v5c9XrGalo7coDwQTR/Ukt2CdzN7SJu+89A6pBFCsZ/a0yRmujS8VH1WZ0H8LZW23kcuxn3k1OHop7NfWSyjjYKmxqsTFht8tvmJCSi/KLewf0m1yYLQUDVOR/1mqAKbCLgXJJtQwtDTjw+3ECexBb3oGwLppkK7eZ9I0aPjBZ08BSUEmS50Q23LrpPKUcR6tIJpcxsuZ+J70cRy37DkHV9EILkg4QuqLduwP99YYHtoi/tCGW+8zFSCC35D9EfNd7cDFjOTvAaKMmGN8NPyjgTfaq3EPLI2HcUw7/0D7qCsf3vYDC+D3JITCdrZkhqm9+UM+iKnwGz/3Pr1hK/fQFJrA2S16pPz1R4vAy1f06OdRLbPNADsFvuN/jRHi1hL/P6Y1jPIzhsQipDa73XR/Galj481M5vU+GrFBhB0PQsIi/n5+5vVWV5r3el7kcytyV7Qf0DgfhWkJ+fRdPFjx86doqxxE+61ig22xQT3gdocW3IRtoQ/TRDh8axOZl96b3fwKobkuqP9JZY2U92wl6FUdK1Drd+e1B+r1CI3BcS5TGOeUGj6 7b+iTD1L +bwcnyjj/dBvdkNK3DhlgrJCn09FAoUgbeB6zWcyaPjeBsTZFYnRHu0RNgw4gJ2R+KzvcPKszMrSVg+OU0PMHjKUvNejNrtm6/lKlBThdIZVrfDW/GiPIUVMkVDQzGp0zYgvOtj4AiOPJOsiPNDP7atXnxRmF8HPesyHMq3OY5ArvlRBi2Ycwft3hcUlydfv+qMM/Tg3vqqDh7ZspA7ZohMK2zpLuWkjHOw70nyVVLQFhSa8X+QVem1FqEtnZgVpBrMtT7+ZzeFk4yogH581DD28WvJ0B0gBgEuLSrFnIKykAIuQV2wcyAuscvwCy3OkM+tV+TwZFGgkBACA= 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 4/10/25 22:17, Johannes Weiner wrote: > On Thu, Apr 10, 2025 at 05:19:06PM +0200, Vlastimil Babka wrote: >> On 3/13/25 22:05, Johannes Weiner wrote: > > Ah yes, it would have made sense to point out. > > I was wondering about this check. It was introduced to bail on > compaction if there are not enough free non-CMA pages. But if there > are, we still fall through and check the superset of regular + CMA > pages against the watermarks as well. We know this will succeed, so > this seems moot. I guess we didn't want to avoid the fragindex part of compaction_suitable(), which in theory may not succeed? > It's also a little odd that compaction_suitable() hardcodes ALLOC_CMA > with the explanation that "CMA are migration targets", but then this > check says "actually, it doesn't help us if blocks are formed in CMA". Hm yes. > Does it make more sense to plumb alloc_flags to compaction_suitable()? Possibly. > There is more head-scratching, though. The check is meant to test > whether compaction has a chance of forming non-CMA blocks. But free > pages are targets. You could have plenty of non-contiguous, free > non-CMA memory - compaction will then form blocks in CMA by moving CMA > pages into those non-CMA targets. > > The longer I look at this, the more I feel like this just hard-coded > the very specific scenario the patch author had a problem with: CMA is > massive. The page allocator fills up regular memory first. Once > regular memory is full, non-CMA requests stall on compaction making > CMA blocks. So just bail on compaction then. Right. > It's a valid problem, but I don't see how this code makes any general > sense outside of this exact sequence of events. Especially once > compaction has moved stuff around between regular and CMA memory, the > issue will be back, and the check does nothing to prevent it. Yeah, it seemed to fix a real problem and we both acked it :) but it's not ideal. Maybe the true solution (or a step towards it) would be for compaction for !ALLOC_CMA only use non-CMA pageblocks as migration sources. IMHO it's just another symptom of the general problem that CMA pageblocks exist as part of a zone that's not otherwise ZONE_MOVABLE and suddenly the watermarks have to depend on the allocation type. And of course for the high-order allocations it doesn't just matter the amount of memory in cma vs non-cma parts of the zone, but also its contiguity.