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 7132DD2068A for ; Wed, 16 Oct 2024 00:41:27 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BE1FB6B007B; Tue, 15 Oct 2024 20:41:26 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B6ABD6B0082; Tue, 15 Oct 2024 20:41:26 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A0B7E6B0083; Tue, 15 Oct 2024 20:41:26 -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 802F46B007B for ; Tue, 15 Oct 2024 20:41:26 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EC170A1918 for ; Wed, 16 Oct 2024 00:41:08 +0000 (UTC) X-FDA: 82677611436.19.B194CEC Received: from mgamail.intel.com (mgamail.intel.com [192.198.163.9]) by imf15.hostedemail.com (Postfix) with ESMTP id 761A3A001B for ; Wed, 16 Oct 2024 00:41:15 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="YezaGeN/"; spf=pass (imf15.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1729039140; 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=QJeVgjRdfQtwIh/zhuRAn91CG0q4WPNGZqy8qCJaJig=; b=fnpfIL96aF/ShuOyLv4wGff5X3DC7bmoLM0of9CzOVQTJrkkQmUVg+00OgHDdZFfhmbZft 2fo8qoaMgWbgwFE+6gJrkwnDxRGwkx8uWjisWVhhASbe7BWAL7Jil+/9BoT6l/rV1SToHt mizc77FbZ/VCganttYoXwIgrBZGyVY0= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1729039140; a=rsa-sha256; cv=none; b=8NtZCxE9qQIciK4w3P6JjuS7zIAVsce1Gsix+P9ml1zGuUbcxNtYkVkla4/kPGnbEU46T+ UZVsOHpVUw2Zu9fjGW6LY1NKklN4ZGmnh9yFuPIDQexQufRTtu65onLbcojVGDENWcPuky pPvoZysPxgz957mLP4MrEPvbHRvUvBw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=intel.com header.s=Intel header.b="YezaGeN/"; spf=pass (imf15.hostedemail.com: domain of ying.huang@intel.com designates 192.198.163.9 as permitted sender) smtp.mailfrom=ying.huang@intel.com; dmarc=pass (policy=none) header.from=intel.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1729039284; x=1760575284; h=from:to:cc:subject:in-reply-to:references:date: message-id:mime-version; bh=Bdstmo2yItBp026W3l2cFUA0w3hl4eeyAPQuG47t38c=; b=YezaGeN/zQEjev2kYALFKrmdJQApL3DZ1Wx88YXVkAfak303RJE3Gl3K bK4lNx+ZtwdFH7ZPwCweOLIZ2m55bZjPkl7WV+96gqW6Buz4638rofFaa ECoqs2b9oZS/FGRGtjkw1evzsWE8rGCSaMP/srTQe87f7ZFdi/X+DzeOm GLzlSu2Q1ZGieUwoB5w8bDYP/nRMrbwsg2fSo3p1g4rIOG43f5HYvb+c8 Dix49JvB+ht43IbOnwjfVBwuz8/NLZpfpqCTF0zja/BzXqoPwzFfARBYu 5Funtw2+ZHGzxmhyjhvCm7kba2/FxpU8nrx1Px1ibW0zHIm0xcEzVtsFM g==; X-CSE-ConnectionGUID: AAPH3RLrQLibfpfTqshLdA== X-CSE-MsgGUID: 8mTnZ0hqSUGvdvDi/cl/tg== X-IronPort-AV: E=McAfee;i="6700,10204,11225"; a="39100505" X-IronPort-AV: E=Sophos;i="6.11,206,1725346800"; d="scan'208";a="39100505" Received: from fmviesa008.fm.intel.com ([10.60.135.148]) by fmvoesa103.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2024 17:41:22 -0700 X-CSE-ConnectionGUID: pBdjQdzeSwuZo/YI7sGKww== X-CSE-MsgGUID: qSdwtueqRcy6IxuulO7G1w== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.11,206,1725346800"; d="scan'208";a="78131210" Received: from yhuang6-desk2.sh.intel.com (HELO yhuang6-desk2.ccr.corp.intel.com) ([10.238.208.55]) by fmviesa008-auth.fm.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2024 17:41:20 -0700 From: "Huang, Ying" To: Dan Williams Cc: David Hildenbrand , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Guenter Roeck , Nathan Chancellor , Arnd Bergmann , Jonathan Cameron Subject: Re: [PATCH] resource: Remove dependency on SPARSEMEM from GET_FREE_REGION In-Reply-To: <670f0209ab155_3ee2294c2@dwillia2-xfh.jf.intel.com.notmuch> (Dan Williams's message of "Tue, 15 Oct 2024 17:00:09 -0700") References: <20241015051554.294734-1-ying.huang@intel.com> <942d18c3-f9a8-482e-a166-c7c9d6fb28d7@redhat.com> <878qup94jb.fsf@yhuang6-desk2.ccr.corp.intel.com> <3450df1e-dcb2-495a-8fe4-0a6e096429fd@redhat.com> <670f0209ab155_3ee2294c2@dwillia2-xfh.jf.intel.com.notmuch> Date: Wed, 16 Oct 2024 08:37:47 +0800 Message-ID: <87wmi87uhw.fsf@yhuang6-desk2.ccr.corp.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 761A3A001B X-Stat-Signature: y6e8sn1u6tfnpk196cgkn4rgwyb3pot4 X-HE-Tag: 1729039275-932827 X-HE-Meta: U2FsdGVkX1/Yk5BmmF6OVN4i1wnsjz1n8TP2kUR077WgZVdU8aNcfHC9BoiH68V/mfIP6MXO5Z+TOVvX1DbUr400oGc1qj72bRip0q2DgydP2dN4ojfNqLNW6Em/AzcPsnc4eVqbYmt+prJQfCOo81ZF80zejDa0xr3eF3YmGWM08eedp9mV9RHAdzRBzdQLGPyVu6soxcEA6hnQ6XLhJScQ35Rbg5dMlOda3hD+3uCoB4vbxjlShN3f1KUdxtPevpTsyILlrDMslJ74A+kUDrfynyiJ6A/clldE//jFzEtIx5n/XfvtidOrxm4M9ZvehG8e5djaNfDYeD6xzySKG5YY77lnsn7Qlt+Ywxi3ytiBLCILHHN8sHgFtc4q/SzZSYMA3bq2SmpdxGjAT9/LhMz+B0KSlXMc/lbutRit89SJa84dxb3BhrM63DTcoBu+nBR7q2vuuZYI/cLneA1UZvng36FKRmFIytGdiBxeAEvWdTUc8+cDvSDfQp/L7bEGQ2r3rYxUp3AOET4tGoJZ8JckOrOGB+5ZSS5q5bxvYW8+1qw5MIszsrUYhLO/XB4iiki6ZuByacIalynubKGw/ugFzb0JTMBHznlFBngzw+PjsxQ0ny3qipfamK+X6BNiIs5bJ2fqcSg0w64mgYJ5bSA71QM+upvdjOiYBs8yXcOY1B7E1VM+KwalYwRfYPOdQjqxj4/VHPxXtfMAXBud8W81B9A1ySnfDFk73Pd0OIrPMU3IcC8sBKeICJRzN2xCDjt6fFaTudWzL+eu+0cmJBh2ESvPDSxO5sG2wozFGvDpqX1C6lhng5mABIYH24P/wH+fUTbnlKu68uLw/M5YKImlEDURlo6iGUh59QM25HJ89uiiNqExPuzO/dA89XFTcheu6bb7HIPHbpwkWr6QqAfKaCgjmT7ymLabVwfJXf9Wc10F+fnPKu62hMmuuETxlOW4ZD4X6dWPTyXIj3l VtRuHFjH 4Rc3DABnyhATfi7yuztPqfNMbT18Qtg51RxPrsgQOU9ltH2AtrufkUIPOwNvOFTaOXQTzGGPa22zxD1x6+wRSIK3QsgR2Kx/P2bRqWUhf53Pi7LtBRoifAenRjka18lkPOJk2gcXlEux3S5ZGI4yLazdugbC5zMNnzcjqDbP6XfVjbxp1b+iVfnnFJNQUcducvrAl2PKpzSyx+01XsTHjitI5SZ4/GXsElgOTs4aRULCW6w8xK8vwilThI3daNY6DrKTfaAMiXmnkAzG5sCUhMPEZzdtLlBdOAWCDiPwfrV5TciYBQZZ3PI5FQkMUR8++UTkD3UzwzepiS5R/bn2JGMp985jWzLaXxBDiJeetbvuWBArUnKSrHYG09g== 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: Hi, Dan, Dan Williams writes: > David Hildenbrand wrote: >> On 15.10.24 10:03, Huang, Ying wrote: >> > Hi, David, >> > >> > David Hildenbrand writes: >> > >> >> On 15.10.24 07:15, Huang Ying wrote: >> >>> We want to use the functions configured via GET_FREE_REGION in >> >>> resource kunit tests. However, GET_FREE_REGION depends on SPARSEMEM. >> >>> This makes resource kunit tests cannot be built on some architectures >> >>> lacking SPARSEMEM. In fact, these functions doesn't depend on >> >>> SPARSEMEM now. So, remove dependency on SPARSEMEM from >> >>> GET_FREE_REGION. >> >>> Link: >> >>> https://lore.kernel.org/lkml/20240922225041.603186-1-linux@roeck-us.net/ >> >>> Signed-off-by: "Huang, Ying" >> >>> Tested-by: Guenter Roeck >> >>> Cc: Nathan Chancellor >> >>> Cc: Arnd Bergmann >> >>> Cc: Dan Williams >> >>> Cc: David Hildenbrand >> >>> Cc: Jonathan Cameron >> >>> --- >> >>> mm/Kconfig | 1 - >> >>> 1 file changed, 1 deletion(-) >> >>> diff --git a/mm/Kconfig b/mm/Kconfig >> >>> index 4c9f5ea13271..33fa51d608dc 100644 >> >>> --- a/mm/Kconfig >> >>> +++ b/mm/Kconfig >> >>> @@ -1085,7 +1085,6 @@ config HMM_MIRROR >> >>> depends on MMU >> >>> config GET_FREE_REGION >> >>> - depends on SPARSEMEM >> >>> bool >> >>> config DEVICE_PRIVATE >> >> >> >> Added by >> >> >> >> commit 14b80582c43e4f550acfd93c2b2cadbe36ea0874 >> >> Author: Dan Williams >> >> Date: Fri May 20 13:41:24 2022 -0700 >> >> >> >> resource: Introduce alloc_free_mem_region() >> >> >> >> @Dan, any insight why that dependency was added? >> > >> > Dan has explain it some what in the following email, >> > >> > https://lore.kernel.org/lkml/66f5abd431dce_964f2294b9@dwillia2-xfh.jf.intel.com.notmuch/ >> > >> > This is reachable from the "Link:" tag in the patch. >> >> That should be part of the patch description then :) > > That Link: does not really describe the history though... Sorry. I made a mistake here. > The description I would add is: > > --- > > When get_free_mem_region() was introduced the only consumers were those > looking to pass the address range to memremap_pages(). That address > range needed to be mindful of the maximum addressable platform physical > address which at the time only SPARSMEM defined via MAX_PHYSMEM_BITS. > > Given that memremap_pages() also depended on SPARSEMEM via ZONE_DEVICE, > it was easier to just depend on that definition than invent a general > MAX_PHYSMEM_BITS concept outside of SPARSEMEM. > > Turns out that decision was buggy and did not account for KASAN > consumption of physical address space. That problem was resolved > recently with commit ea72ce5da228 ("x86/kaslr: Expose and use the end of > the physical memory address space"), and GET_FREE_REGION dropped its > MAX_PHYSMEM_BITS dependency. > > Then commit 99185c10d5d9 ("resource, kunit: add test case for > region_intersects()"), went ahead and fixed up the only remaining > dependency on SPARSEMEM which was usage of the PA_SECTION_SHIFT macro > for setting the default alignment. A PAGE_SIZE fallback is fine in the > SPARSEMEM=n case. > > With those build dependencies gone GET_FREE_REGION no longer depends on > SPARSEMEM. This looks great! Will use this in the patch description in the next version. -- Best Regards, Huang, Ying