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 CCA87C83030 for ; Mon, 30 Jun 2025 22:35:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3AAC76B00AC; Mon, 30 Jun 2025 18:35:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 334956B00AD; Mon, 30 Jun 2025 18:35:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2238E6B00AE; Mon, 30 Jun 2025 18:35:06 -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 0DA146B00AC for ; Mon, 30 Jun 2025 18:35:06 -0400 (EDT) Received: from smtpin09.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 7FAC71601B9 for ; Mon, 30 Jun 2025 22:35:05 +0000 (UTC) X-FDA: 83613523770.09.2E976DA Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf25.hostedemail.com (Postfix) with ESMTP id C5BFFA0002 for ; Mon, 30 Jun 2025 22:35:03 +0000 (UTC) Authentication-Results: imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=aLNA9Hmy; dmarc=none; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751322903; a=rsa-sha256; cv=none; b=SF2JWYBN10c1umyqH+3xDuBzQkpFiMsvppbx47sQPb1NDlxWsTiwSvT8YeAGhHvhvRP5bq YXIucWf63JCDdnnVh5/cuLOw+56pa73wRWWgttkHE8n2fxDIsa8nbm/gi4KYP5o5btrosz vBQJuQXvxxjDgv8cjo1w3yTIThwQy9I= ARC-Authentication-Results: i=1; imf25.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=aLNA9Hmy; dmarc=none; spf=pass (imf25.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751322903; 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=jWupAZGyNWfrc8KLtOD8gxmKdDv2TzSOf8bykVthRv4=; b=DjidmjPos01kEmLpOfIcwBiITJziaqU0LQ7P4n3HEGadGdthPrU+BqpiAdZZR1pa+VUO+y AK8tzjnsv3pbVkQc+uMoTz4PT5B+rCNepbIwlTJ1EpIntXxSz2V6Mvco9Yo662ix92HiDK 662jCYB1g/gWYJSP4p/6BDaEaJmAkdA= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id CC1D860007; Mon, 30 Jun 2025 22:35:02 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1B7CDC4CEE3; Mon, 30 Jun 2025 22:35:02 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1751322902; bh=ce8Cwit0P9uvsqHgJ2VoewpjioHRndHSgnVlcFV7jiM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=aLNA9Hmy6i1HvsFiv0tFkbY/H3/yEd2uBGmAQM07lNmJ8qgbr6KfAwK0zKjQYkNkz rVUXKSwhL4nlHKfnIoicDp4zEF1BZOfhX79llchH3d1hIHMOg/YFZaCpvcOuQo7oQb YXb8+EKzroNuWdJ5IDZ/7ZpmT0pSJUg1/ePVoLFU= Date: Mon, 30 Jun 2025 15:35:01 -0700 From: Andrew Morton To: Joshua Hahn Cc: Kees Bakker , Gregory Price , 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 Message-Id: <20250630153501.64160f386faa541c93344e48@linux-foundation.org> In-Reply-To: <20250630202115.1439224-1-joshua.hahnjy@gmail.com> References: <7c1180f4-923c-4138-b756-618cb5d597ac@ijzerbout.nl> <20250630202115.1439224-1-joshua.hahnjy@gmail.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Stat-Signature: 8ecn615j5kkzdqnwsrsqkuutpod8d5a7 X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: C5BFFA0002 X-Rspam-User: X-HE-Tag: 1751322903-900616 X-HE-Meta: U2FsdGVkX1/uqAwtN6J1hz6mYFRK6YFarOXgiA/4+PsokxML9CGI289avvXtqXg6Edz83dOEX02HDl4LmJtXcxz/18ogcP8Vo4NoDRdEUxv6bJEZsi1pMqrluSfizqKuzZ6L8UcE8QMrNfTxeO2EcoTljiOJDhSzQHmdBA2EfQA7GWUBCvuS0Fy8jqt98MA3KE+i3qH2Rm+uwsd3PknekDm6Zfr0VFavQGnRy01wbMo+aJRkssKYDEhzmg0HABskt2lQqEFPyjEQjuDp5/urknkTz5CkTVWXPjXJQDZp6nNL1i0M0dSo0ZLCN7PHrZ3L6RvJv883lFHnGD883zzxGEanmLMiAycSEPSuscla5n4aBj8pTGkz/KQxSnOIYvcEWGg17f+H7sJ2iq9pqdVyU8jLoIZ13tMmflpyYkoq2EBtG/FpgcQvxi5j8HafAFVjyEt/U5ZsHiAkK3cAEMKld/k7u5o3o/Gdpzt+l29v5fxJOqM+kg9kTugREPLZEFCftubAeSacIIUGcC6R0j7bp14DBDJWktKry5Ij+gy9Qq+NYSbg/HAPvTacq3HSNjpsS25EJktoD5KtIpxAjgDJfSIhizMbgaPaKj0SVZeqBW8F35xXkMLuXKyWe9oL4mnqEhkd+ZThzfP4tOP6ki04NBRr8AfFzJp3DbjSRq5ABbnDeT6a67PUYqt95OKoHBA9+yC1yyGLwIaS2zYEtm1MXqWPxbDARhvHUXovW1LYv6ZqGo2ENocbXqTe6/oziPc2j2EMzoSJY3l4r9EzJDLc4sx+E7ddeBrsjS6TkahTu+1A3TXn8njuCbJ1HYe7Cv+UGAf4b8suhA68iKOXYjvm3tmqKTqsAwAETm0iIQlbGRr1nOQOEh8Okd4843j8a8yz5C1yRG+D9yRYDpoEt4gz+mqBxtjsTkGCgr5YVKoAWBsLD51RzzaAAYXzyfNyGdQQ+BnKzfg+eoVj17GrNOC vf8PGYKA wKMgVkx2iApB6bXUkfcZCgfLMjoTlFmVP1JiXnCSgO7m01gRaczysTNEuGTNzLy7hZmz0rXHvU4eDq1lbru52un+BvJ+ZblJo0Y+/CMr55/SsPtE5daOnJ6TGyy19Tyw7/3aGyeXj9L8EgInQ/yAKPT2BnUWvf2vq+HNwtlC3wI8WgGEV/z0QzQm2r748y911Zskvlvv4m5XiJUbEo8Szrq33B/NQv4s+ucaoYNnUiTjgayeakgWEoor0DvXnEIHuvlY+OaIuCk1o3gObXvLENV77iMmLTwO5xB00Wn7gyYNmAGXFt2Rz6zi9KMJhFeh07UlqXPA8C8Ow4rTbAXaVVJ3Lh8kveFB8P+Li 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 Mon, 30 Jun 2025 13:21:14 -0700 Joshua Hahn wrote: > > This is a goto into the middle of a for-loop. > > What do you think is going to happen at the end of that loop? > > > > I think (only tested with a small C program) it will go to the start of > > the loop, do the i++, check i > Variable i is uninitialized at that point. In the loop it hits several > > uninitialized variables. > > >From what I can see from my code, I think the only the goto statement leads > to a second iteration of the for loop is if allocation fails. > But otherwise, it should be ok since we always hit > > if (total_allocated == nr_pages) > break; > > within the loop. For the branch that takes the goto, we set > node_pages = rem_pages, then jump to the label and allocate. > So nr_allocated = node_pages, and total_allocated = 0 + nr_allocated > so total_allocated = node_pages > > total_allocated == node_pages == rem_pages == nr_pages, so we will break. Phew! > > To cover the case where allocation fails, I think we should be breaking > anyways, so I can definitely add a new check for this. I do agree, that goto is a "goto too far". That we can do a thing doesn't mean we should do it! > > Even if this is legal C code, it is pretty obscure. > > I agree that it not very clean. I did this to reduce the amount of repeated > code there is. Even if this code works, it could definitely be written > better to make it more readable and maintainable. As I noted in my second > response to Gregory, I'm not planning on pursuing this version anymore, > so if I decide to send a second version, I'll keep this in mind. Cool, I'll drop this version from mm-unstable.