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 B6005C77B7F for ; Fri, 27 Jun 2025 16:13:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 56A3C6B00B4; Fri, 27 Jun 2025 12:13:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 51A456B00B5; Fri, 27 Jun 2025 12:13:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4092B6B00B7; Fri, 27 Jun 2025 12:13:24 -0400 (EDT) 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 2B7146B00B4 for ; Fri, 27 Jun 2025 12:13:24 -0400 (EDT) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id D685A55EB1 for ; Fri, 27 Jun 2025 16:13:23 +0000 (UTC) X-FDA: 83601675486.30.B0925A2 Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) by imf07.hostedemail.com (Postfix) with ESMTP id 323454000C for ; Fri, 27 Jun 2025 16:13:21 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="iNP/f31K"; spf=pass (imf07.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751040802; 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-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=dR5MPIlTa2PoYXve2Gi2m66jUTuWCrLna8bHb+jCXJM=; b=rxmGuR8KgBIwkOFwPxU4IJL9SEnTRS8l6phj1F/FEqV/iCrcGF1f2Aa12g2wd6eUrZazvD G6nI03gt9BWzJaOhjvGrmSe3oZwUC0AEY1G78Lisi1JHtolbjnYHdQO9rvrUYyaqiO1YrQ P/5zv75kudtbT5PrSkMaSx7UV4FA9WE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751040802; a=rsa-sha256; cv=none; b=Hx3cGfiWTNwXAr2sznVueDIAqhs77EQACBZSSPNUGS3kxmQHL/4sMCeXfJgb7nIP/Qaibu 6lh2+smkWT3Y9s481GhS77fzMes7BUa/yqLjND+OFQ5yrSF6LMEQx2XS7ea5LoeRqYBkyf 4C0ZceB+qWwOhyLauJQIWlkMw3csd/g= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b="iNP/f31K"; spf=pass (imf07.hostedemail.com: domain of joshua.hahnjy@gmail.com designates 209.85.219.181 as permitted sender) smtp.mailfrom=joshua.hahnjy@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-yb1-f181.google.com with SMTP id 3f1490d57ef6-e75668006b9so25407276.3 for ; Fri, 27 Jun 2025 09:13:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1751040801; x=1751645601; darn=kvack.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=dR5MPIlTa2PoYXve2Gi2m66jUTuWCrLna8bHb+jCXJM=; b=iNP/f31K6dt1PnpQIUAp4ZIta4E57o73BHhxV8UNxRXfz5MZXHQipXYRTA5qg1eht5 yCzaQ2/ucUsbmn978sfakt3LohRG0KWCWSEaEmlc5otVJ4TVJ4aNN7/ekuyO+B0zfCp6 ZtUxuIC5e44coK1Oj9opfAMx7R4B8JVy9wwNB3NYyqS/dP2RnKw+3td2ZKQTGWi49oUz x9JmU1+H7KZW85p9FpyI8MDfhcteakCben1dHsoLK5DCxV2WwoxjMs1RQbMdveasKZzf LppXX4Q3diNg53FVZu+EG3lFWfHMp3rPo5KbaKpq3s8UVe+c9aM1+VnXGZEgioT6hg1O 3qKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1751040801; x=1751645601; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=dR5MPIlTa2PoYXve2Gi2m66jUTuWCrLna8bHb+jCXJM=; b=RwgUAXdorlWI54gT+aXss/FkUuv/pX4P6UHvzKhhlWUwuxj5so3C9Daa13eVuvuJvA SwSBYnzd/Po7rj1DLh0we2iJca+YbEdCsJgzaQO/LhvC1vCm7ARYYAMk3hgcU8DRckV5 j1qlEoz3o5JjYhvyy0RGaS70BXpWS3nGEJXOlF7iy7gs1wmDgrXdw3aztg97xJtZgF5u ihAXaW5agG+VTTmiK5wV3NSsqiCfdbNX3rMljwKGC4I2aCJkgKZNyHqlHjg12naap9oy ykkxqixeLY9gRbm+xwKmynh1ldO6YxO0zBKxUh98arzTcKfLCmgzv8/NgVKd/+94gQSQ 25rA== X-Forwarded-Encrypted: i=1; AJvYcCUh2gjIgVdZL8seRiPElFHnwXAfprybfS7khEJGF+N2PHJaXteImr6OGLa2/Mc0nNO8TURsOnZJyA==@kvack.org X-Gm-Message-State: AOJu0Yxc/mZXfKNJH+Y4lY9QOcGb6BQiGf3FalBS2zNAcP5dw7MHSb3V YDC8NVEjMv1yvpjqnXJMmFTRMI2ToivyAgzljWhI9y8kyQjpLSXxEbWm X-Gm-Gg: ASbGncuqz+MWPcdTFXtFL8+NR5nloucEaSu4fbvBjCISyYnvpAjJ/Z0O7YP96g26Vty 7ECzwmaFtLh2yUsPDj5HGZ3LhhZ/0t5XZw0vNZoYoDrwokmA/mNMJLb3KbDS1CYTFZTqZd2HhGd tQJOlHHSLGZLUjGh8OJM82s6unkEdusCVkWyK72XAJzKl4vl7BlekFL4pPLSBA980lHui5keCN0 udnycj6ndyV3tz2Krw18nYNdlX73DFrFH1nYm9T+lXuBZvwhsm+Vunf0ZQgMeIIF6ZTuLiRL49u kaaEP/bh+aV1bAveRgGBJFVhFTnLM+HA56NFuCoSofgVL0MwtfpaZPFlIK2/nw== X-Google-Smtp-Source: AGHT+IGYoGw3Y12KQQ+u7jOP+q4hfx5i8DJ1Ymkci1iQSqm6ujlUokE29l8NKgb1YWii/pFbW8GX7g== X-Received: by 2002:a05:6902:2ec3:b0:e81:f864:133a with SMTP id 3f1490d57ef6-e87a7b01d5bmr3464143276.7.1751040800830; Fri, 27 Jun 2025 09:13:20 -0700 (PDT) Received: from localhost ([2a03:2880:25ff:11::]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e87a6be423fsm646653276.47.2025.06.27.09.13.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 27 Jun 2025 09:13:20 -0700 (PDT) From: Joshua Hahn To: Gregory Price Cc: Andrew Morton , Alistair Popple , Byungchul Park , David Hildenbrand , Matthew Brost , Rakie Kim , Ying Huang , Zi Yan , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel-team@meta.com Subject: Re: [PATCH 2/2] mm/mempolicy: Skip extra call to __alloc_pages_bulk in weighted interleave Date: Fri, 27 Jun 2025 09:13:18 -0700 Message-ID: <20250627161318.1898633-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.1 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Stat-Signature: 5rparney5bbwerwpm4mi5nmh54x1wdux X-Rspamd-Queue-Id: 323454000C X-Rspamd-Server: rspam08 X-HE-Tag: 1751040801-658924 X-HE-Meta: U2FsdGVkX1+plKLJeC6/HCCzdicz+2Wea/oR7pXDwrZ1AgjhIucX5zhjSN2OmLUBYQAMjbbqFemAB58LFbUu8hz5piTeD87mmdqNJZVDDrKUKN4dYvypTwiH5P0dEnQiQxCyJZale7xg5Jfxf7kllIdATC51bKqQmL4BOerNyk1q6KluGvUFfZlLpqRAsL6wn+IUGDwaXM3SCJ0Mq76ILb/O+Su2C/h9RWd4HofhS13LN+XYu/lgG2MAjWYxh68/fSnF+nO9t3gIHz1vAEZyDe021MdmRqxjdRqyDxuysubdvaZD/MHnlWLjg/1UxVUiVuO/w90eoMlCV+t6cAeMSvS9GgcoNVayb+dIEUqE8Z5+kJaa1xH3CU0oqvLqv74ZijThfH4E/2zD7wn3GYn96mDDwgwzRkU0Z4EAFtugNkXNZxp9tf5IUyKl3T9A+HMmxFjZHSFC1ixZmxkG7hb8EGRbPApfV7dUtpUXlyWeaFLRPBzw4HStghlBjHtc08siJppZhusArADdzF5kH25Na9Eu644CAJa8s4clMmqLgPwS8zu7vvl8dHQ/O6o7HRav31fmwa03oOaDHpEU1rCvDPJFEY1n6OIuboJ1NIxiI/1lHFRwH4gIqUj0cR8r73Fj/GIOJyOSPx/9kz75fz8u4D2wPsRHe7qowuVNvraQzPcA2xW6NZzVuwqLqxwyy0LPrZvRslnM8J54/tJgDlCxJvTZKmJpmVIbIdzE0Zvi8T4XvcSSGXS+8xf02tA2d11hSzyPWcP2oIkVo7fcg9kR3EfQu/sgPcZUBHe+SWQwVGmZkY2LC3pvddrasAYTuWINMAqQ+EJTksY9x2v7vc7NGnkNeSs+D3HsgWq5TPJqoUhmR9UqjBQC+IAvCz3hgS0i0lTJlVctOe6ftqnzW4HSQZej504z7l+TLuJPmOI0h5mC8mDD08uA8T6ZXlr5PD23l2JuKp77OdXFiMPl3oZ Iq0L8j4u z8aN2Tom5UIyUqgOmYo/hvpVu1qdbPxd+yr8p2QabqJ4Rr2b6p0jKkJFKXZDxuK4TvRzYNZIRaxDQzlxyERbtCOHFW9qTpqXQn3OO9+A2nNAe85PdgtOki5e25sg4NyPmX7Rzp5A4yRgu/5ME9Bm9Lk+S1er04BvU3amlQerdavrndRl7rmzgjYQWoQ== 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 Fri, 27 Jun 2025 00:28:33 -0400 Gregory Price wrote: Hi Gregory, Hope you are doing well : -) Thanks for the review! > On Thu, Jun 26, 2025 at 01:09:34PM -0700, Joshua Hahn wrote: > > Currently, alloc_pages_bulk_weighted_interleave can make up to nr_node_ids+1 > > calls to __alloc_pages_bulk. The additional allocation can happen if the > > previous call to this function finished the weighted round robin allocation > > partially on a node. To make up for this, the next time this function is > > called, an extra allocation is made to finish cleanly on the node boundaries > > before performing the weighted round-robin cycles again. > > > > task->il_weight can be operated on by other weighted_interleave > functions in mempolicy, so it's not just > alloc_pages_bulk_weighted_interleave that affects this. This is true, and I think that's what makes testing this part of the code tricky. I'll elaborate more below. > Observations here are still true, just a correction for clarity. > > i.e.: > > The additional allocation happens for the current il_node/il_weight. > > I *think* I did it this way just because it was easier to reason about > the two chunks separately. So I don't see a reason not to improve this. > I will say that, at least at the time, I took the core math and > validated the edge conditions in a separate program. > > If you get it wrong in the kernel, you'd either fail to allocate - or more > likely just get the wrong distribution of pages. The latter is > non-obvious unless you go looking for it, so it might be good to at > least add this test result in the change log. It's hard to write this > in LTP or kernel selftest unfortunately. I think so too : -( One test that I wanted to do while developing this feature was to see if I could figure out how many pages are really allocated from each node. The difficulty in doing this (as you pointed out above) is that because there are other ways that move the round robin forward (without necessarily calling the bulk alloc function), it's hard to directly attribute the page allocations. If this was the only place that we were modifying these values, then a correctness check would be equivalent to just adding a printk of each node and how many pages were allocated on it, then adding all the numbers up to see if it matches the weight ratios in sysfs. So I think I will do what you did as well -- I think that performing some tests, at least on the edge cases in a separate program will help give some confidence that the code works as intended. I'll also continue to think about if there are better ways to be testing this instead. Thanks again for reviewing this, have a great day! Joshua Sent using hkml (https://github.com/sjp38/hackermail)