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 139C6C0219B for ; Mon, 10 Feb 2025 07:02:58 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 793686B007B; Mon, 10 Feb 2025 02:02:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 71C0C6B0083; Mon, 10 Feb 2025 02:02:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BD116B0085; Mon, 10 Feb 2025 02:02:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3E06D6B007B for ; Mon, 10 Feb 2025 02:02:58 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id BA6F646AB5 for ; Mon, 10 Feb 2025 07:02:57 +0000 (UTC) X-FDA: 83103142794.18.361169B Received: from invmail4.hynix.com (exvmail4.skhynix.com [166.125.252.92]) by imf22.hostedemail.com (Postfix) with ESMTP id 2D061C0007 for ; Mon, 10 Feb 2025 07:02:54 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1739170976; 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=mMJ4lDwqM3FRHTiX1pP93Pl9gZu8zBGMRAvt5zcpxoU=; b=yShqSMmOov1XUSAnJqWo/rjdmkKDvW1l2Pa5BLGZKauoD2BsSQAXC47bvEkOvKYq9E+XSc LilHojMwIt5xMsXOMd7/oRrQswLbV+Xz3HCkFgak4Dj0eKSHybclOHbZX3JZsUxBHiVIzJ GSmo/Lk1er6okRwjsPq0oWMgQQiablk= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=none; spf=pass (imf22.hostedemail.com: domain of byungchul@sk.com designates 166.125.252.92 as permitted sender) smtp.mailfrom=byungchul@sk.com; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1739170976; a=rsa-sha256; cv=none; b=6JNAILPnBCNPVZGP1UFWjlkw2tyhR/oEff/u+lS8RKhOwMki9KLSB+wGRlnCTAbBh1QZP6 NwbImRmKg/QtRtF8rAn4JbTLx+WeyMq1uD1OvOZ7VLqP3qy56rrln+X/JByxSlbO1skFwT uNVMCFN513a8IKBW2WD1CEccUGSja6E= X-AuditID: a67dfc5b-3c9ff7000001d7ae-7f-67a9a49c09aa Date: Mon, 10 Feb 2025 16:02:47 +0900 From: Byungchul Park To: Gregory Price Cc: Matthew Wilcox , Hyeonggon Yoo <42.hyeyoo@gmail.com>, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org, Honggyu Kim , kernel_team@skhynix.com Subject: Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier Message-ID: <20250210070247.GA39454@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+NgFrrMLMWRmVeSWpSXmKPExsXC9ZZnke6cJSvTDZZu07GY2GNg8fPucXaL 87NOsVjcW/Of1WLf673MFr9/zGFzYPPYOesuu0d322V2j80rtDw2fZrE7jH5xnJGj8+b5ALY orhsUlJzMstSi/TtErgydlzYz17wmb9i4YwfrA2Mc3i6GDk5JARMJD4eOsgMY587u48VxGYR UJX4fuwCmM0moC5x48ZPoBoODhGgeNsV9y5GLg5mgUeMEtvf72MDiQsLpEm8/eEHUs4rYCFx v+cUK0iNkMBORolZ21tZIRKCEidnPmEBsZkFtCRu/HvJBNLLLCAtsfwfB0iYU8BM4lLjXTYQ W1RAWeLAtuNMEKftYZO4sIwFwpaUOLjiBssERoFZSKbOQjJ1FsLUBYzMqxiFMvPKchMzc0z0 MirzMiv0kvNzNzECg3pZ7Z/oHYyfLgQfYhTgYFTi4T0wY0W6EGtiWXFl7iFGCQ5mJRFek4VA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxG38pThATSE0tSs1NTC1KLYLJMHJxSDYx1kw8qW8pG nSuYVWrFGNU2MyvVNbGSQTmJ6elTibux0ed4y/OvOAX5LttVI+sm0jn7BWuPhPvh6GCZZSoh DOttFNfc1Jt3Pur4vsM1Fx9p2RzeMyvWOSBEXjes7BZP5kdDpVmrru4oPBobq2K5eJdBzhLJ /82pV3WPLjF2X7NPsKY6pPHKOyWW4oxEQy3mouJEAHHsIzNmAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrCLMWRmVeSWpSXmKPExsXC5WfdrDtnycp0g5WnFS0m9hhY/Lx7nN3i 87PXzBaH555ktTg/6xSLxb01/1kt9r3ey2zx+8ccNgcOj52z7rJ7dLddZvfYvELLY9OnSewe k28sZ/T4dtvDY/GLD0wenzfJBXBEcdmkpOZklqUW6dslcGXsuLCfveAzf8XCGT9YGxjn8HQx cnJICJhInDu7jxXEZhFQlfh+7AKYzSagLnHjxk/mLkYODhGgeNsV9y5GLg5mgUeMEtvf72MD iQsLpEm8/eEHUs4rYCFxv+cUK0iNkMBORolZ21tZIRKCEidnPmEBsZkFtCRu/HvJBNLLLCAt sfwfB0iYU8BM4lLjXTYQW1RAWeLAtuNMExh5ZyHpnoWkexZC9wJG5lWMIpl5ZbmJmTmmesXZ GZV5mRV6yfm5mxiBYbus9s/EHYxfLrsfYhTgYFTi4T0wY0W6EGtiWXFl7iFGCQ5mJRFek4VA Id6UxMqq1KL8+KLSnNTiQ4zSHCxK4rxe4akJQgLpiSWp2ampBalFMFkmDk6pBkYuv+mrbnjO qdnu576dkXXJT+XL11K+TGPKtK4LaJe9kJH9IWpvRMnDKSt1dl1yZH/CtnLy0RP11Ue1Va78 Oe+V9PlO1In36SsTWx5slzipeVKOM2f3Znfe4z9/CMz9XvovsnfXKneT6p9ZU960TblqUae+ cYbtt2T5r3u65m7eOe+QbpdGZ8N2JZbijERDLeai4kQAjYfA+lcCAAA= X-CFilter-Loop: Reflected X-Rspam-User: X-Rspamd-Queue-Id: 2D061C0007 X-Stat-Signature: nh4rfr8taijr6axps3oom86fa4kx7s1p X-Rspamd-Server: rspam03 X-HE-Tag: 1739170974-41931 X-HE-Meta: U2FsdGVkX19Q0ZqBC3Kck+jGPG2vM6CvQLJSZAPAzfUPct1xdLPJuSRtXgEmwgxu2DsjK1CajAraZKazvXr75qLrJT3/odM1yWUiFN5RPcL915P2HO1W2autQVBm76gVKFMGHln6jFdRIhdtUXpR/x4N2jTlDs6d0I5/zAyTnzPqduVxFGLJOmJTLRInJ/UNmP50TlP+hJONwMIgowBN5+jpQ5CeruHAQ5QcoEngg/s5F/TcqL6U1VdqoY/jqdnha/lIrDLxo/EIdYekETjbm97AmnC0mYLf76fTO+AcZRoH6e0UvllBBsF7fybSGJDSMknfUD4pB4RM+KuYFrHafZsjrf84UJyJU5MJcjUIcZi35InGxt9oxgqPwVTwqjU2N4BxtQw7m8PcRZzOV7zHh/dmNj56k7AuPPjUBdH775aWGMLbFDyXHfBttzBm4lgnlJkhDWzgmG6ixdBhd9R8t62yxgjr2Xs0tYUGOgswZ06jO8tWLVmM3uHkoGt0MgDQxXOkQ2Ii9ejphESwYcrHtsGzNee9eHWpNqbud0p+vOcnKh24E550TGfvgA8rmmLQwSdHaWob/w3RK+PEljLoosRkQFnhClccIwvrKBqaqZqLePTa/RT6ny0gqnUIOP4bT7/oK0cm9AoVfSXtl5MyU4h2pLce11WqcsprmZejAVaTQlwZas9e3yo3IxImYCliPX3t0npeY5hNXxdPtqhEoBX1hRz19ETDLc/GTZF6S37j2E/p6r4XjwhMW+dKdKV5T2cPU7cHC3cepGRzYRTd3qa1YaU+59RFNoVNFYB088SvBaO9SympEaaN9JNYNA4Olyhi3rHxfW7uKJIZbvLLQ6YaNx3XEBB361e6NTkzhA4ADIiarEtok/I/3uyK/Vc4EuH5swGauHml4VOyFf6kwx3v03EmoNYuDhMHEegkev5CaaHsLZffV7rNzXncc1qz/hjifbKrh9Mo0q8lEvP Mia3qHTI 9JFkI 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, Feb 07, 2025 at 03:57:45AM -0500, Gregory Price wrote: > On Fri, Feb 07, 2025 at 04:20:24PM +0900, Byungchul Park wrote: > > On Sat, Feb 01, 2025 at 02:04:17PM +0000, Matthew Wilcox wrote: > > > > We can work with from the easiest object > > >e.g. page table > > It's more efficient and easier to change page sizes than it is to make > page tables migratable. > > It's also easier to reclaim cold pages eating up significantly more > memory than the page table (which describes pages at ~8 bytes per page). Sorry for leaving comments in an excited manner last time. Lemme focus on what to consider and how to resolve them: Case 1. A system with no or little non-DRAM capacity You are right. It'd be easier to reclaim cold pages eating up ZONE_NORMAL. ZONE_NORMAL in DRAM probably can cover whole memory. Case 2. A system with very huge non-DRAM capacity ZONE_NORMAL in DRAM might not be able to cover whole memory. So either allowing ZONE_NORMAL in non-DRAM or allowing some kernel objects to be placed in ZONE_MOVABLE would be required. If all the guys agree with Matthew - a system should never be able to equipped with very huge non-DRAM memory, then yes, we might not need the discussion. Case 3. A system with a capacity between huge and little non-DRAM ZONE_NORMAL in DRAM might or might not be able to cover whole memory. Quite big amount of kernel object would be still required. Of course, properly reclaiming cold pages eating up ZONE_NORMAL in DRAM might work for the purpose. At the same time, any efforts to reduce the ZONE_NORMAL cost would help and mitigate the pressure on ZONE_NORMAL in DRAM. Here, the efforts include e.g. reducing size of kernel object, making some kernel objects migratable, and so on. Same. If this case is also the one that Matthew and others think is not realistic, then yes, we might not need the discussion. If not, we need to consider the issue. Byungchul