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 CA26DC27C5E for ; Mon, 10 Jun 2024 06:08:50 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6021A6B00A6; Mon, 10 Jun 2024 02:08:50 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 58B406B00A8; Mon, 10 Jun 2024 02:08:50 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 42AF36B00AA; Mon, 10 Jun 2024 02:08:50 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 24AE16B00A6 for ; Mon, 10 Jun 2024 02:08:50 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 96EF2160D50 for ; Mon, 10 Jun 2024 06:08:49 +0000 (UTC) X-FDA: 82213950378.28.6EA330D Received: from sin.source.kernel.org (sin.source.kernel.org [145.40.73.55]) by imf18.hostedemail.com (Postfix) with ESMTP id 845031C000A for ; Mon, 10 Jun 2024 06:08:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=J0Ra5EcI; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1717999727; 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=p9t1JxdGY/BYtFFeJHNJAB24SvzK40wW1PSsRWlXa8M=; b=nwrmhTSfoB9ZEkDMSkNMZ/r5foScjou4SQLlGE9Bcv8ElSJICVn8WcHFqe6crb4tsPf5MK ZfKtS2Z3YFiRNWFgBNzM9eTAN5FYtdynnvQxj6cHIyS19fRAactctwSfMde1vc/14xiTQG MnSmdalO7sdsyAsrkf8O/xrCq3hNZ5c= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=J0Ra5EcI; spf=pass (imf18.hostedemail.com: domain of rppt@kernel.org designates 145.40.73.55 as permitted sender) smtp.mailfrom=rppt@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1717999727; a=rsa-sha256; cv=none; b=WRQ+r7LzGSqfyakrZvQQ4T8bHTEDb29qwsQXpmhpArbgWKnlXfCtTFKiyxD7at0TDYq+Kj sc0pwVTgD0VNPDpTE7tM7KN61xGKsLYh7UIVZA5len/oNlgQb98BQ9lP2sEvjhWtd2z/dT g3jqvuIXZcR7KOgIleJpXcD8D3FqNW4= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 47CFACE0F95; Mon, 10 Jun 2024 06:08:43 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9A06CC2BBFC; Mon, 10 Jun 2024 06:08:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1717999722; bh=ydU3TIHzs/gqixC34SQ/HlD8nJN2Njc1bqn94VBCax0=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=J0Ra5EcIeboqGZAuts2bhl2iJ4p1IlqLcdNh3qNs87zOoIaH5ldNi9pwIS+l8aU9C WlkzxmCZXpqK65yajDYqFaSJ3VtUkB01x29ploDFSPS+ZduVnL4MaTTtIaXtSCL5G9 ttRmi9kxGw2/pMOD+lefA1e1YHzj75KKzCP7zBurp0vOJ5k5qpj2oVMTtNVE2wn98P gXGFSpHR0dKRCFlP4/gdM4bRgoWwx13WnDeqsPvSmDt/oVcfIF3uyPTy8CA3yqFl50 WL8VJZ8oxUvtdSGsudL+my7hZgeBrvwMwCnUQkZAUCbZEvfdUZ2wipjNvLSyBuSmIO crKV8N+8sPYVQ== Date: Mon, 10 Jun 2024 09:06:37 +0300 From: Mike Rapoport To: Leesoo Ahn Cc: Andrew Morton , Leesoo Ahn , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm: sparse: clarify a variable name and its value Message-ID: References: <20240608152114.867961-1-lsahn@wewakecorp.com> <20240609140341.14ba3a1c62029771d60059ed@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 845031C000A X-Stat-Signature: m1a9tj8uqcteqp8876yuiukss64ixbn4 X-Rspam-User: X-HE-Tag: 1717999726-175065 X-HE-Meta: U2FsdGVkX18DQP7LE3UvxaUVNjzsxolKz6mBuTQTW3VzHkN5M2B3xbXow8tje7liEDeAfDlrIcJY30et0rnjpJLBuq6fYv7XwykxEFFjHG7q9c8YQmjWbx+Zb0ftSWrk6/tPEiR9gruLp/16eICmNkUNBw+y9AdLE42vwU3fySlgRwwfNx4nQyve5dpRo/U7BMxxrppYM2jo8WWGpziDiiUaT96R+wqzPNNwqYMJCl+8eZsl2EGGGxYDZaeDgbxeKaaAwtZVFIv31Wi3FulbIzNlqbySeJ7jQ9HqTUhUSYm02WtBtXRltM5eQ7x0YNPnjba8rXT6p/kS93Bog7p41dSuVu5TkD/3T3Wm19/G5aVNSr8mm1dwbXrOzwEQNHZXds0RW8eo0EzX1grX3/BRPwY/7Q6xRso0T4Tqou671uZRrSUUvlXDc7xfNDuUjY9xM/NTErSqYdmIe6zYrohJzCbAL1aqEau7mZokYy06waOQ2E0PBoh3LkIM/26UkxX4c56KiyGbhtoNoqpF+ZHUs/Y54GZYC6hLxsBMj7BDwc2H+mtniXLcWa4ksHM4cO+I76lyguhaDtU814giAwDX2cdt3ZGXw1EcWejGC6v9S3FZktyK57Ymvs4sXrWuXBdQJcZlwErUZkHohgguaMpMnJmcSM8zWr1PnlKBid413P7TceSyvbR8OWrOhtphAi7SLUieKWO7M3duoXuc3yyHZguNhGMPiI7WaRsFMdwJonr9wsvzgAOgN/4GlGGsKYWPk9ZUhflOiAS4m+DgMepIXkfU+bdFR+SsIXEc4qWD37JsJc8rYH34TI7+lCYPLvR6Gbj6Okc1GWi43RMVFwEiudQcQT4UZA6yCU4X99vbFVjcwJduy9zNChb2zdlIgK+n9BYoEz5uizEqn2Vot5t35kIXf9NA/YPTsw0Pa+jAi8u5ZYf1jd88jlfvrh8cBRn5oDFd/r8VbykuMx+BTvF UUGsUc26 +TnuAZ/bEhOPko6NXCwwA7Vf8/wVPloOP4Hni8dmrHDq/0sAjAH2sqHXJDsL2Rng6y1FDU3ft6Kf1xFH5goBMfo4kcplrR7QRyTTkfO/IqqmIjAu1yLu/4vSoKAxUdFBN+Gv4CJDOy23flJq1fxNcWxXCBaQ+DV5P/evU7HrRWNIIhBT76SEH0vdR5RNiM7vu5lGO5XkeuFvIrgBCey1XonzN/tL4WWiUTfsfqdikEW4K2icrJhP4uqJNToA6e2ObnP+78FEX6MRzsHugaTvSBnFlzuvXlXSOcyIVHgz6lSRV3J3vKkhMxxAQfJ0kMO73vlW6e61iZlygU5M= 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, Jun 10, 2024 at 12:39:28PM +0900, Leesoo Ahn wrote: > 2024년 6월 10일 (월) 오전 6:03, Andrew Morton 님이 작성: > > > > On Sun, 9 Jun 2024 00:21:14 +0900 Leesoo Ahn wrote: > > > > > Setting 'limit' variable to 0 might seem like it means "no limit". But > > > in the memblock API, 0 actually means the 'MEMBLOCK_ALLOC_ACCESSIBLE' > > > enum, which limits the physical address range based on > > > 'memblock.current_limit'. This can be confusing. > > > > Does it? From my reading, this meaning applies to the range end > > address, in memblock_find_in_range_node()? If your interpretation is > > correct, this should be documented in the relevant memblock kerneldoc. It is :-P > IMO, regardless of memblock documentation, it better uses > MEMBLOCK_ALLOC_ACCESSIBLE enum instead of 0 as a value for the variable. Using MEMBLOCK_ALLOC_ACCESSIBLE is a slight improvement, but renaming the variable is not, IMO. > Best regards, > Leesoo -- Sincerely yours, Mike.