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 75230C02198 for ; Mon, 10 Feb 2025 07:17:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E09A46B007B; Mon, 10 Feb 2025 02:17:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DB9C06B0083; Mon, 10 Feb 2025 02:17:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C34B76B0085; Mon, 10 Feb 2025 02:17:51 -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 A06116B007B for ; Mon, 10 Feb 2025 02:17:51 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id B810216056A for ; Mon, 10 Feb 2025 07:17:50 +0000 (UTC) X-FDA: 83103180300.18.32A326F Received: from invmail4.hynix.com (exvmail4.hynix.com [166.125.252.92]) by imf11.hostedemail.com (Postfix) with ESMTP id 1FE7140007 for ; Mon, 10 Feb 2025 07:17:47 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739171869; a=rsa-sha256; cv=none; b=NZH13ixxgaJx5vtHWkqVgc+pad5rDipg7vxyAhCfpOSr3cCBFIO6AAlw/CewgAiUNHHOKv Ytb3KIvksjSJb0x9o3jR59JXdJeuEJxMqkRoadmaenIYZ5OYPMqgN/Bpq+KzGXK/zeN2Md Outl4GcDBZWvYAsRSmASO49auOGxC7c= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=none; dmarc=none; spf=pass (imf11.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739171869; 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; bh=KaSuHaJssZvWytwkxBuD35+mV7vMhZy1VuRvdvLA3Ng=; b=e4m9HeJhxIoxv9AbxtUeR7J2KMRNoFzpxyapQppjflIqBcF7oRmlT+FhvxYvdHnoD5cNs+ /eGx3wQNkew/S39JAa7bm343JjEDU/kexIKrdCGf+b6RczHgSzslRiB3S4zjJFd8xDHFZo 9eMH+MRMYjt65JFrgiKuWi3T6JLCbzc= X-AuditID: a67dfc5b-3c9ff7000001d7ae-26-67a9a81af303 Date: Mon, 10 Feb 2025 16:17:41 +0900 From: Byungchul Park To: Gregory Price Cc: "Harry (Hyeonggon) Yoo" <42.hyeyoo@gmail.com>, Honggyu Kim , kernel_team@skhynix.com, Matthew Wilcox , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier Message-ID: <20250210071741.GB39454@system.software.com> References: <20250207072024.GA48419@system.software.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMLMWRmVeSWpSXmKPExsXC9ZZnka7UipXpBi1nRSwm9hhY/Lx7nN3i /KxTLBb31vxntdj3ei+zxe8fc9gc2Dx2zrrL7tHddpndY/MKLY9Nnyaxe0y+sZzR4/MmuQC2 KC6blNSczLLUIn27BK6MdR3n2At+8ldcn9zP2sDYwNPFyMkhIWAi0fLnPyOM3djxlQnEZhFQ lXj5dwJYnE1AXeLGjZ/MXYwcHCJA8bYr7l2MXBzMAm8YJf5t3MgEEhcWSJN4+8MPpJxXwELi wbQlbCC2kMArJonlu8wg4oISJ2c+YQGxmQW0JG78ewnWyiwgLbH8HwdImFPATGLSpGPMILao gLLEgW3HmUBWSQjsYJOY0XqFDeJMSYmDK26wTGAUmIVk7CwkY2chjF3AyLyKUSgzryw3MTPH RC+jMi+zQi85P3cTIzCol9X+id7B+OlC8CFGAQ5GJR7eAzNWpAuxJpYVV+YeYpTgYFYS4TVZ CBTiTUmsrEotyo8vKs1JLT7EKM3BoiTOa/StPEVIID2xJDU7NbUgtQgmy8TBKdXAqJ18ePaD cGcB9X3un2sNn7Wy7z+gn+W/6/nvC87iLw55sAVJH8wwjeB5eOI/z5m30XfP+QaGnJVUK8t6 bmWZ3923MHGCE49v+OJ+h5bDm748vTLrrUMwb0i2C8/x+8zbOk+5FgXttG2y+JXUmFSXvLlL IMI28YQ51022JQzK3V+yeDlEfokqsRRnJBpqMRcVJwIAn4ZuOWYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrMLMWRmVeSWpSXmKPExsXC5WfdrCu1YmW6wZ8f3BYTewwsft49zm7x +dlrZovDc0+yWpyfdYrF4t6a/6wW+17vZbb4/WMOmwOHx85Zd9k9utsus3tsXqHlsenTJHaP yTeWM3p8u+3hsfjFByaPz5vkAjiiuGxSUnMyy1KL9O0SuDLWdZxjL/jJX3F9cj9rA2MDTxcj J4eEgIlEY8dXJhCbRUBV4uXfCYwgNpuAusSNGz+Zuxg5OESA4m1X3LsYuTiYBd4wSvzbuJEJ JC4skCbx9ocfSDmvgIXEg2lL2EBsIYFXTBLLd5lBxAUlTs58wgJiMwtoSdz49xKslVlAWmL5 Pw6QMKeAmcSkSceYQWxRAWWJA9uOM01g5J2FpHsWku5ZCN0LGJlXMYpk5pXlJmbmmOoVZ2dU 5mVW6CXn525iBAbtsto/E3cwfrnsfohRgINRiYf3wIwV6UKsiWXFlbmHGCU4mJVEeE0WAoV4 UxIrq1KL8uOLSnNSiw8xSnOwKInzeoWnJggJpCeWpGanphakFsFkmTg4pRoYnU885Kx/vYR/ rrbMMudPzxf++frr7meek7u2pFwX6/v+7JRv/jTBtjWfhKvKZ31mcFqget+gkyt9RteKiNLf 0fF/tvmvO3Rtqm9hsGib6dX7Wu0X7Kbf7X6wLfz0mWemdz8sbRWwPVEw21RVflqja+u6p74T eradOntmo6Df3GTlJrsWj6jcVUosxRmJhlrMRcWJAHZl8DtWAgAA X-CFilter-Loop: Reflected X-Rspamd-Queue-Id: 1FE7140007 X-Stat-Signature: cdxwknmios1x9w7rea3ycos3u4gsk5tx X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1739171867-609731 X-HE-Meta: U2FsdGVkX19JAKTgxZRccJeSgb1rl4TLdXeuTj+caBENIKveC+2P7sxZ+469u/KSAAFTi/lrkRmMDvNEnPTguLcFNRPqxyXWPVDEEaIJ+Y8ohAUhewD+ge70MaNNZM+qj2YgDgWZJTulqrHc7XtBoXx+36E//n0LwNLV+Eh2CxJSRFoxDyDdDGCjLUcWS3WQkVxbh/p/rxTv2R0FfsAnyzW5Bx1mW98m4k9utoTkqJScbYAt3TmYjbbPXZWYv5a9p1OYySCIIN5EVUf1eTN5Pi9ijPSS18BuiVHyiknPfLq7pmY7lbWywVWq2Uplq5cLip+vVPnnXC+H5KTL7qE9guFLHXCWUNTUY2mxAX+gAyThF6MS5RszdMNBFlsA+gnAoqTYvOfm9Ul2qN1blCgY3pTfKIOxJ6vf4bi1x/5AnWEeoi9mIMDCXcJAc+FzrtNjtDXbpyPIubC70sKjIyezX6fIpswWtmO/98tG7zYMvgzfbMAl0kMqR9mnkkZvgU7Aj/EhUXuriRT1T34bbBkwoJ0199o/8Av4qp1x4YDthl6enciaNWozmNcum1HBzWPUgCfrQjbGJ61cfPAvpIKuc0crRNONWtAVBp0xyHpZCMXaZfcyshlS3ttAoJhvdniEEZKGrdb8OYCVufYjYwRTHft4Rl358BCqkibCroiaDTNRq46gpDkkKCM4O/YYrUra+Vh33yDV7sda/Al768VlAxEX7+apsy/xsCea48f4J+Ha5D8hVfsI7ZufQv5wJ0VWGJ0ZlRp/SuBnoGWmFDWGQkFJbAa0q20Ftr6lMtGFuHt2skltuVO2X4p3HNEUirsL5VxeaZ0sUClLyPVU+7xDlipFPAhGz3GG0X0BosFRkuQy+2qIVP4B5lGwfuJvtLxwvtUPgh2QpiPHV/3z1WEtaoOt8wZijlmHTmsHA//tItb4/qhYHjHO1YHJ/K4d3tFC 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, Feb 10, 2025 at 01:00:02AM -0500, Gregory Price wrote: > On Mon, Feb 10, 2025 at 11:33:47AM +0900, Harry (Hyeonggon) Yoo wrote: > > > > Premise: Some ZONE_NORMAL capacity exists on CXL memory > > due to its large capacity. > > > What you actually need to show to justify increasing the complexity is > (at least - but not limited to) > > 1) structures you want to migrate are harmful when placed on slow memory > > ex) Is `struct page` on slow mem actually harmful? - no data? Then we can hold this one until it turns out it's harmful or give up. > ex) Are page tables on slow mem actually harmful? - known, yes. Defenitly yes. What can be the next? > 2) The structures cannot be made to take up less space on local tier > > ex) struct page can be shrunk - do that first > ex) huge-pages can be deployed - do that first I'm really courious about this. Is there any reason that we should work these in a serialized manner? > 3) the structures take up sufficient space that it matters > > ex) struct page after shrunk might not - do that first > ex) page tables with multi-sized huge pages may not - do that first Same. Should it be serialized? > 4) Making the structures migratable actually does something useful > > are `struct page` or page tables after #2 and #3 both: > > a) going through hot/cold phases enough to warrant being tiered > > b) hot enough for long enough that migration matters? > > You can probably actually (maybe?) collect data on this today - but > you still have to contend with #2 and #3. Ah. You seem to mean those works should be serialized. Right? If it should be for some reason, then it could be sensible. Byungchul > > I don't understand why we shouldn't introduce more kernel movable memory > > if that turns out to be beneficial? > > > > No one is going to stop research you want to do. I'm simply expressing > that I think it's an ill-advised path to take. > > ~Gregory