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 EF00AC021B2 for ; Tue, 25 Feb 2025 13:34:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3DA886B007B; Tue, 25 Feb 2025 08:34:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 38A326B0082; Tue, 25 Feb 2025 08:34:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2530E6B0085; Tue, 25 Feb 2025 08:34:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 071DB6B007B for ; Tue, 25 Feb 2025 08:34:41 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6B21F14152D for ; Tue, 25 Feb 2025 13:34:40 +0000 (UTC) X-FDA: 83158561920.22.DD11C08 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by imf12.hostedemail.com (Postfix) with ESMTP id 74FB340008 for ; Tue, 25 Feb 2025 13:34:38 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qmVS2jGk; spf=pass (imf12.hostedemail.com: domain of jackmanb@google.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1740490478; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=1XPlcI28gI5oChrIiNVecq25q0LkKn4pW0JK0o6KpS0=; b=PIIJ2xw/eN+Y31S71esa1TEjqFUdYQoiSsDpQMidhE88B9cP4LUNfsLX5nCehJM61Wbk7G UQoAiEZ7lkujnrNgKkx95DgulrvvdUNDKPC4/M0MP4tLDOyxgt0nKO6T34rwI+Sx5Erxpw 0jqe2aTYQt3fgvuLQz3Tv/23f6tNeko= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=qmVS2jGk; spf=pass (imf12.hostedemail.com: domain of jackmanb@google.com designates 209.85.128.46 as permitted sender) smtp.mailfrom=jackmanb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1740490478; a=rsa-sha256; cv=none; b=VD+2ca8MQjVIkPZoFDvba9rcez/srFfTbeBN1pMsXu0ZByNkmz/SCOLR5Uw+u601gVZVtB eeWn2SroCEGIIpXQP9p8DfudvOo6AsYtNQOacbE4LX5vgpS/sst8SgWPhDLdLR34g0CTGe 6Rcg2D+3+T+aZ6YqDhL7zlZeUWsSBKU= Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-4393ee912e1so40675e9.1 for ; Tue, 25 Feb 2025 05:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1740490477; x=1741095277; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=1XPlcI28gI5oChrIiNVecq25q0LkKn4pW0JK0o6KpS0=; b=qmVS2jGklxKq20QiaoKqgXUTAW4lVJJqyFPmrMZPn6JTaYtqil5O5ZR8plbXrFwYkJ g1p/RwinX/8LBq2cjInfDy14lsuiDO6vCwtytiASHpp+7F1M01T63nAMTB45D5LrnRDA BQEaMqyKumr4yfzxD9iHdgn28K1r6u4xxvsaSgvUI3xKX4HPk9FFkTXkrx4FvKlf6zbY w+RBOjieIJ6VbgpwYhSjx/rLLN3lUGcJc9yG7iYqZ4+H1jFm1O24j2Ko5XvpkXjG8hYM iNziv74ryEY77/rob+OE2Lfr+74xx0RAhWvb31whuFNnIQEyovvm8u3wpSZQqX/3mFKd tBAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740490477; x=1741095277; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=1XPlcI28gI5oChrIiNVecq25q0LkKn4pW0JK0o6KpS0=; b=LCSfU+Vi6IcyJ8Kg0lFgWR99m6nK8zaRqcDVF0UfhvkVZC4BtS5IiSF+MpdHF7tsmq ctxIdU3eCjApzqo3sfrJhlOAeaHPCnF6rIWtQvwgBCjxN7mUZnGqim3/Iwln2I3k+Uhc P/t6o1HVJopa3VQlxrfsoK+fQG6uU2McwJdELWS6AxhghOwjoNdYN2PI4ki/eAdAHlwf wOvnwGT6F1jGs1Up7JdnY08F/WKr09bFaBqSuPLKniWhmFxo0f6m2qmBnaUI6r5DRrBC JDHu3fIJhcycE7Z0WqJGB7dT//1hpmyQ94f4hOLm0fr8FonjEk/CMjPAjEDTYIi6wNHK vEYw== X-Forwarded-Encrypted: i=1; AJvYcCWEtVDjiySpK1XK0ztcHk7/WxlXWvp5NWEiQfX20oP7wRwnrRQV9JsHEF/b4m4js+Sgo1TXL+zyrQ==@kvack.org X-Gm-Message-State: AOJu0YyhjMEWLOXrcpRsUKcSIAWmbk1lGC3/ti5lQ0mcIwiOUr5bDR9g Y6FR15dPk7tAfn/F+t8U8BuxE3H++5cL0dlfoYE1raSR1Lx4V1GH8IFSZ+LsIU0IL03Co+KVjSD mqQ== X-Gm-Gg: ASbGnctTrjXU3KyQ8nrLUf/6vLp4fV6QvWk70RAF5XF3f/J2n7h/AQVX0THdvov5iNH BK7A6ubBNV/r+JrBNl+6ff6i1YkofPDWtbNV7hE3uvyvkhBfsahHHDkGAPx4JpH4FduFQB4pqmp GHq6FPd8+f4h7UaujvGoLAW85qodyd+ZXstfhdR5gE8NE1lpq7vnS7NAEkQuKWihePPo4i2Zmvk QOLVLHI8frpxbDOqBZOM5exbaSZ5SoL4rQ+Z/qLP+6RXHuR+4R/k4+ft7VSeNEkBIvMZpxZY5xK IFN0jCjgk8KHiDHIe5ObTkFSOGcTb4mGN+D2IwZA4NLvkp0SrYYqbvwWM90AoA== X-Google-Smtp-Source: AGHT+IFgarIShp/PegXB9yEBD9d5JJwHidwtjyIFC7IcNoRQMLs6o2EYyQwp8nXRryIOXgFHEMrOsA== X-Received: by 2002:a05:600c:56d1:b0:439:961d:fc7d with SMTP id 5b1f17b1804b1-43ab10378dcmr1431035e9.6.1740490476743; Tue, 25 Feb 2025 05:34:36 -0800 (PST) Received: from google.com (44.232.78.34.bc.googleusercontent.com. [34.78.232.44]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43ab1546f77sm26215295e9.20.2025.02.25.05.34.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 25 Feb 2025 05:34:36 -0800 (PST) Date: Tue, 25 Feb 2025 13:34:32 +0000 From: Brendan Jackman To: Johannes Weiner Cc: Andrew Morton , Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/3] mm: page_alloc: don't steal single pages from biggest buddy Message-ID: References: <20250225001023.1494422-1-hannes@cmpxchg.org> <20250225001023.1494422-2-hannes@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250225001023.1494422-2-hannes@cmpxchg.org> X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 74FB340008 X-Stat-Signature: h187cb69yqgnf5rcjxy3jmmjcfx5en8e X-Rspam-User: X-HE-Tag: 1740490478-324386 X-HE-Meta: U2FsdGVkX198iS2YM+h7OvqhNQwxfevs523IQe4/yZ7Gtvig5YNSpUHvdT7iN2z4tvDmd5OPbTcGXDZtE3aj37SMW9wbGHRgN9nu2XugW6nUXsnoO8DY3ITxmqrMYJsY3R8fh3LB4Vr/IHwJ1/dLmF0ldYA2OEv5FM6D/veScoR/774PqLjwtlDTfwXol6v3DM6QCat06pZDhMJiVh+/kBcQOR63Qy8G8tjnkUz0YHST1t/Mb43Y2U4/jHW90oNG7RTXvh7sZHU4IKWiqwhicm0VUQV3ohHAkk6Azp3jZRgDUzaI9yRDx1ILmA0kUp4x2pRwvX+ncWncXmsgKwfSKa/TPKU+VS9Im4FzXZEd6zdIvjYo5bpVH7gCavkKBEL/queHv+tcNCsA1Kl4Z363EOyLUOvmGMTlDDDhlK9yBKxcMfe08U0zgWFJbwNeDX5RLGhluinQvvu5k2aZ+SwkPWGD0VRS73Hvoy2cCGuXhEp18i3XFLxNhcFwHWAgrpw1U9Bme78h8MJ9RuMeJtx5r3hcYNIcnyrEHrEgtH58FQpV0BaVJzVpohsGb/MaS8YeuiJYtkitCFrhe6Kyslr+Wnsjfebd2h1oxDQ3eNrpjjym/VEgLxn/s2pcaCGa24ULjm18/xsJ3NY5VVRah2Sb75sNUJ+Nx1onJ/DGmzrN0uITQUcv1q7rI0EkXuNZBlsGxWCfqrw6uh0HfJMB2AZImXL32rT75f/aiDeT8uYB7zn22jFXwnuYwrO2tAimwcqKVqTRd23+/45meR4GIQkV7SccxLToE6XAIR8Ho78Llo16GPBv9WUuISN3Jg3tH41mHBQOUwXqGl23sr4TYEbVPbzLDJfyconSBqc+kZZwB+u8DVzOGBSiGADiMv2jsVZhS9Sf8T1snhTLXs84Tu9+XO519T5VSv+l3RzT6MvKK+HoM+Ka4A8WwbW18HYiYR1LNu5+SawKz8hB6uDUz2u x0ygIkRr mU316p3/+2ERIivLDuf3l0tsxsEzp8qy2KfzHiRYCvCh7GqiEJEWTW0nSBGF34YnOc7zxsiDHZ0u+LgsjyehAWx9xJHPYqXzLkBBk1G4V5VeY2esbrH70C2O5S4jWnk7U1Cj68z7OZe8MmJ9K9OtxUo75asO2oDoLwgMKnCZRsWkauxuMevgbZIGiAWUfikMBQ4Y/lMTknmgUQc/qnpxyredTDSc2cGm3CyyiH3jRFFIwUQWBHMuShT8baTWOQo1rlW3SUR8RC36IbXZkS0/LbBdB8tAXIm2gVZ1XpPrR36kl90W9Eof/092G4WJV3Esjo/MZ5L0igljWiVVSiNGgt970NnyU4pB14wiXCp53UHoDnZnSrKSCPxFmc0bPqcJh3z3u9t/9dLqL4E2j32LGvAPltw== X-Bogosity: Ham, tests=bogofilter, spamicity=0.010998, 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 Mon, Feb 23, 2025 at 07:08:24PM -0500, Johannes Weiner wrote: > The fallback code searches for the biggest buddy first in an attempt > to steal the whole block and encourage type grouping down the line. > > The approach used to be this: > > - Non-movable requests will split the largest buddy and steal the > remainder. This splits up contiguity, but it allows subsequent > requests of this type to fall back into adjacent space. > > - Movable requests go and look for the smallest buddy instead. The > thinking is that movable requests can be compacted, so grouping is > less important than retaining contiguity. > > c0cd6f557b90 ("mm: page_alloc: fix freelist movement during block > conversion") enforces freelist type hygiene, which restricts stealing > to either claiming the whole block or just taking the requested chunk; > no additional pages or buddy remainders can be stolen any more. > > The patch mishandled when to switch to finding the smallest buddy in > that new reality. As a result, it may steal the exact request size, > but from the biggest buddy. This causes fracturing for no good reason. > > Fix this by committing to the new behavior: either steal the whole > block, or fall back to the smallest buddy. > > Remove single-page stealing from steal_suitable_fallback(). Rename it > to try_to_steal_block() to make the intentions clear. If this fails, > always fall back to the smallest buddy. Nit - I think the try_to_steal_block() changes could be a separate patch, the history might be easier to understand if it went: [1/N] mm: page_alloc: don't steal single pages from biggest buddy [2/N] mm: page_alloc: drop unused logic in steal_suitable_fallback() (But not a big deal, it's not that hard to follow as-is). > static __always_inline struct page * > __rmqueue_fallback(struct zone *zone, int order, int start_migratetype, > @@ -2291,45 +2289,35 @@ __rmqueue_fallback(struct zone *zone, int order, int start_migratetype, > if (fallback_mt == -1) > continue; > > - /* > - * We cannot steal all free pages from the pageblock and the > - * requested migratetype is movable. In that case it's better to > - * steal and split the smallest available page instead of the > - * largest available page, because even if the next movable > - * allocation falls back into a different pageblock than this > - * one, it won't cause permanent fragmentation. > - */ > - if (!can_steal && start_migratetype == MIGRATE_MOVABLE > - && current_order > order) > - goto find_smallest; > + if (!can_steal) > + break; > > - goto do_steal; > + page = get_page_from_free_area(area, fallback_mt); > + page = try_to_steal_block(zone, page, current_order, order, > + start_migratetype, alloc_flags); > + if (page) > + goto got_one; > } > > - return NULL; > + if (alloc_flags & ALLOC_NOFRAGMENT) > + return NULL; Is this a separate change? Is it a bug that we currently allow stealing a from a fallback type when ALLOC_NOFRAGMENT? (I wonder if the second loop was supposed to start from min_order). > > -find_smallest: > + /* No luck stealing blocks. Find the smallest fallback page */ > for (current_order = order; current_order < NR_PAGE_ORDERS; current_order++) { > area = &(zone->free_area[current_order]); > fallback_mt = find_suitable_fallback(area, current_order, > start_migratetype, false, &can_steal); > - if (fallback_mt != -1) > - break; > - } > - > - /* > - * This should not happen - we already found a suitable fallback > - * when looking for the largest page. > - */ > - VM_BUG_ON(current_order > MAX_PAGE_ORDER); > + if (fallback_mt == -1) > + continue; > > -do_steal: > - page = get_page_from_free_area(area, fallback_mt); > + page = get_page_from_free_area(area, fallback_mt); > + page_del_and_expand(zone, page, order, current_order, fallback_mt); > + goto got_one; > + } > > - /* take off list, maybe claim block, expand remainder */ > - page = steal_suitable_fallback(zone, page, current_order, order, > - start_migratetype, alloc_flags, can_steal); > + return NULL; > > +got_one: > trace_mm_page_alloc_extfrag(page, order, current_order, > start_migratetype, fallback_mt);