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 B43BFC6FD1C for ; Fri, 24 Mar 2023 17:49:20 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 19D3C6B0072; Fri, 24 Mar 2023 13:49:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 14D026B0074; Fri, 24 Mar 2023 13:49:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0633E6B0075; Fri, 24 Mar 2023 13:49:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id EBD716B0072 for ; Fri, 24 Mar 2023 13:49:19 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id B87FEAB569 for ; Fri, 24 Mar 2023 17:49:19 +0000 (UTC) X-FDA: 80604528438.07.257A365 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf15.hostedemail.com (Postfix) with ESMTP id 840C3A0023 for ; Fri, 24 Mar 2023 17:49:16 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fEbTH4ni; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1679680157; 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=L97NvfZpT4YYB2rdfhkEMctBAC/jl2cw0YL5PLc13BA=; b=CpOBzDhLKTg+ZLaoXSBGNFI2QLFTgfyjWenckVcv+dAD0BXruuwfQcQBe4DGkQFlXvJ1pq 4YpjywH9FApZzoGMOT/cX6OTRTZzxI0JBhIJ8aut11IF6XXGNROd9te/c43x9wqXWAJxbo z802dDAMbOevrsdaFYxWz5yLO3rQIq0= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=fEbTH4ni; spf=none (imf15.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1679680157; a=rsa-sha256; cv=none; b=nLVER7LG+Tw7QZE/08tXeqg4RmQws1BsGlSwxcDPuAZOWbaR8wpl27SXyxXjPQhfRKNnIG BVBOFcf8WoCp8jxBgynCSVrE5xObJHJHnYiEEGaYxU9bOq+U7rgonOWq6RFno9tnR5+uz6 gIDR+bkZGzuS55B2SZB/NjhhNV6Ohl0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=L97NvfZpT4YYB2rdfhkEMctBAC/jl2cw0YL5PLc13BA=; b=fEbTH4nis2CZPnj27yrwBEsGhj VM8eoqNH3bifgYPWDCswe9n/9bMkqmOy5COrPuXPq4Zk9hgfyuzvaoV5lJnxFOVwlirmh3qGokOap gI8qA0vHgkAiGdwPhOrHDHwh9Ft4PFmhVXByjsyv1q7xoXroweqTci/Lm4OwbZzTHcoqS5K3eWW40 8bwrRv9LAuYDumh0kixTbWDUIaipmMMp0XeQd/Z4WDHZTFY/XyWX78aXnrNGuEoN7z1sO9N6G54Zt dcJ5LLvgtXkcsnx55jlrdO00uFGTjlS7RVsTI8WPbrlIdYiODx7X1RKXfzx6ehe95i1P1hVejhj+o dxXo5IsQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pflXA-00577f-BH; Fri, 24 Mar 2023 17:49:00 +0000 Date: Fri, 24 Mar 2023 17:49:00 +0000 From: Matthew Wilcox To: Kyungsan Kim Cc: dan.j.williams@intel.com, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-cxl@vger.kernel.org, a.manzanares@samsung.com, viacheslav.dubeyko@bytedance.com, ying.huang@intel.com Subject: Re: RE(2): FW: [LSF/MM/BPF TOPIC] SMDK inspired MM changes for CXL Message-ID: References: <641b7b2117d02_1b98bb294cb@dwillia2-xfh.jf.intel.com.notmuch> <20230323105105.145783-1-ks0204.kim@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 840C3A0023 X-Stat-Signature: pdd55wfeph8hdi4dt3tknu9zmqew9pmh X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1679680156-176769 X-HE-Meta: U2FsdGVkX19Jkg8bOFimXm4FaUJf1NjKkoZzbovZzKo9ZfJuW6TanMNkETJbB4yVcMmkfnb9JCYhheFSvs9HHyQtW+kx/vM2rB48k/PCjqMQ8Iy7XuA+hGWJL3S07pAqmE2DlEG4tNWGdluwQHdRGMfMc2DWHwL58k0lm8nAJweoxVixNBrxDKSTU38a6P4/PZzScw9uZR1fUh/YKkmUVRtglrcv+WkSxxbI2lSHzDKpEyoaf9HYFXAhiFKI/i8yZ6gj84PKikVYwmPlJF7TwktiZTWTyWkClFJn9nosXi19tmIF9iMvZVtsO4s09sGiJe8TP1B/OKDVNZLHG4ycWGfe5XJT4aPxGA1g4NVN/aeO0AL0KeYh1r0c0wVvWf8L3wOEMxNX7zPuK/+HSp9yiXnRN4l3VS9NQyYZlxloMxOwVrscwXw3qu4wgaWwsgHUh2U73Nih1et8nrsxRDqW2gT63EtBfq8NIf/WuGpfcxACEaMnGTDtjdVjKiOCMGpWNBqcKvjFurYscAqmAJcgxe/PYXmDa0HVcLu9+fAjDr0Zxp0Em191p9DMSf86lDUgHb4RzBITIomwnwn8OW5SnwtcVqp73eCg2AZEmuZ6uuh+cvzvSLylrRCVHqXHTxoQ4Srn712imzK4wNW+2bd91p61Dk0ojOr7+KqsCfPg6ImNwW3TkDNgVAh/SsEfhggefiScDq4Nr4ZWLVkxhnSLY+ZRt1wHR5hdQUb3phx7EbV4XA2pIJ1hb5HDcTc20BO6aFFK2+CZf9cS3jSK6DBBTEqNwu3fMKB0HJeDSyhDTbUSqb4pPpTMI7wd3akqS5waoEZD+FiCn+PND1yFgy78Xue9PC5oyEUpX2bfz1jiU6inCz8ZFK8+Kbzjji4eHStryZZ0rjfh8vKJ4uJ9khl0q/rpX5TW53k8T+EZfkn2v7gp+gsURzicx2uOHWd1yTkV1W9DhaKkV91q3kYjNW2 X9NTq19r /j6+Z6mzPS4Zm5MwRpcksoZI0epwmiU3lTNmG1yC1G+laaArdD6kjVszjyIIaX/rYWohT3XQGhGPMniPVk8ahmAPnOC+LfKIG4vnaJ5FFM3lrrPbWep6fYt/ew8tU1rIIaJNA5NZ5i1EIWqH5A/hqehMOSeJI6GupErbmJjW+6i/p83Nn5wJjnZwwIC8UhOrus/H/c00mDw12gV0BzfgWDF4lgA== 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: On Fri, Mar 24, 2023 at 02:55:02PM +0000, Matthew Wilcox wrote: > No, that's not true. You can allocate kernel memory from ZONE_MOVABLE. > You have to be careful when you do that, but eg filesystems put symlinks > and directories in ZONE_MOVABLE, and zswap allocates memory from > ZONE_MOVABLE. Of course, then you have to be careful that the kernel > doesn't try to move it while you're accessing it. That's the tradeoff. I want to talk a little bit about what it would take to use MOVABLE allocations for slab. Initially, one might presume that it is impossible to have slab use a movable allocation. Usually, we need a relatively complex mechanism of reference counting where one takes a reference on the page, uses it, then puts the reference. Then migration can check the page reference and if it's unused, it knows it's safe to migrate (much handwaving here, of course it's more complex). The general case of kmalloc slabs cannot use MOVABLE allocations. The API has no concept of "this pointer is temporarily not in use", so we can never migrate any slab which has allocated objects. But for slab caches, individual objects may have access rules which allow them to be moved. For example, we might be able to migrate every dentry in a slab, then RCU-free the slab. Similarly for radix_tree_nodes. There was some work along these lines a few years ago: https://lore.kernel.org/all/20190603042637.2018-16-tobin@kernel.org/ There are various practical problems with that patchset, but they can be overcome with sufficient work. The question is: Why do we need to do this work? What is the high-level motivation to make slab caches movable?