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 00D2BC02194 for ; Sat, 1 Feb 2025 18:49:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 860766B0082; Sat, 1 Feb 2025 13:49:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 80FB06B0083; Sat, 1 Feb 2025 13:49:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6D7676B0085; Sat, 1 Feb 2025 13:49:02 -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 4C58D6B0082 for ; Sat, 1 Feb 2025 13:49:02 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 0147DC10A0 for ; Sat, 1 Feb 2025 18:49:01 +0000 (UTC) X-FDA: 83072262924.01.F0C5738 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf14.hostedemail.com (Postfix) with ESMTP id A8E4610000E for ; Sat, 1 Feb 2025 18:48:59 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NV8NqObD; spf=none (imf14.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=1738435740; 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=6XTLJP6/F61nHWkP7dtkXo/rOgVgMoJSZWYn2PrE3iY=; b=yyYuEwKPln2Uvge++L5kCditR2Hrw7bXwlq/6eAjjbP10oTHjJSLRQAcaslXF64wIvctKU Y23SgU9dNPW5GOILFi0a2F3+i8PjxJL5fPp9HwcUU+DUj9dE2tbOhEOLdbvsg9AsFVqaH/ 0VSv1hy4qVVHV6XG8iieaO1U13kPNI4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738435740; a=rsa-sha256; cv=none; b=DCs2i2mSnw6IoY9hYTXvCK7MGASmN6AX105mwPDgqrsxwKZJ492wCOi6HwMl4qhj736f4M qe/SC+LfVXUmYy0JvB1J0S6L/GP6Qzkg/OuOwPqaO4x2/lDcW7pNDstWOvWM5ZLfjxaQ5P F1yllOEYsQhYbD6Ku6VohcGFUIIJAqI= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=NV8NqObD; spf=none (imf14.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=6XTLJP6/F61nHWkP7dtkXo/rOgVgMoJSZWYn2PrE3iY=; b=NV8NqObD3rMMqD259EEy6xsTdP nPjtliyQs3bhOPmfOZ0j9WLbgx7My/M5aXd2ZEf8FAgHKHr8l+xsTOYTB+1lRAvtpu1Ljr1UhgxEV cJ9J/yr5TuVP0mAUZxv9z2+2kb9N5H+WbdGHRk4bLVBwi6qR24tsaklKBc27LeTCZhDdI582JlLlF EqnydB0WExKg/QB57ID7789eN/9htzorTf8HgMNtOX5+bHIvVG6pajZUVpOuDWhvMhzZhQ8LH/GyD 6Ov+a/xFYCw2pNE5Zw7Y7EYT6Q0saUqvPYTaoulVsG7V7LKXLs4bnCrMS+tit2i8y/sVmzhcIpFQe cqKXwn/Q==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1teIY3-0000000GKYd-3JDg; Sat, 01 Feb 2025 18:48:55 +0000 Date: Sat, 1 Feb 2025 18:48:55 +0000 From: Matthew Wilcox To: Gregory Price Cc: Hyeonggon Yoo <42.hyeyoo@gmail.com>, lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, linux-cxl@vger.kernel.org, Byungchul Park , Honggyu Kim Subject: Re: [LSF/MM/BPF TOPIC] Restricting or migrating unmovable kernel allocations from slow tier Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Stat-Signature: bp9tpftb47w4qm14rra31rc8q49eotoh X-Rspam-User: X-Rspamd-Queue-Id: A8E4610000E X-Rspamd-Server: rspam03 X-HE-Tag: 1738435739-693737 X-HE-Meta: U2FsdGVkX18Gss1aZKe9AV9JndC6PIGXwysqfJDDAMa2N/v4kPG4xzC3izIg1iAltfu6d/9uMHvYCFeYw2FkLFpVcQ4NjKQK9tSipV70U/rWtm8RqctH32pYyv9unpjs6KDJHoa8d90h9wD2+92ezbNtP1GacV8Kvs0JMqoBDM2b5YQ/VQuqYigGe178Q52t3fUjHu3AmAz3z7rZCJi9ypudFLtqIaKg/IegewcB6nRGYKV1hzlym+IwuyZsV27YxB5WsiefMHdt87bAphaSrKYQ/zAykbV2aEco31Siw/7Hh5I9K6SFGPOrCU6WE3UM1bmhyX1oARL3hp+6ZYVx7BhrpDUhWThdgWsNAPqhMwxbkq2spCYX+goEzd7VWrI1v3IiJDD/5kQ8f+yhgYInlhDPo7FHfeZLAfNzS/l8sb9gMDebn1Niy0VB1fwwRjRt/v9HDMtEIlxHG7UVZPOUZgNqVOqwD3HhK1mukWs2P46JFIsrwpKWPB5klqp9ZF3w9PEFZLE0nnmpwtyJ23LICpEZn1EW6wq2y+k6nE4FBogcWOmZTnxOKJRCrUml0JQ4rkXUGPeWQZpqo3fOsoa03Xp+C8hFzretLnZVWbHK1B1hqbZGSx6bZeTHVSsxLCL4gv1bCnPeDNmZdP4ftxgPDgAEVruhpW4LSxYUy5l9hDBck59WGfRDs7k7BsZ3HyvtPvwYWJI1Lpk27woZ4/jtktXj9cZDvSKh0+EZKDaIrwhFpAMOVZv9WozVxpXBfSpfWf4AxIgHXSOoUsF98G9CA1NZMU1/hakKRSrPNA62j3Rz9/yVRDXSxAlDGI1WWEVWk3fX9v6eniyk0Z+0qWWLVJ4nXOiRjHSoZCrGwrGgtL1Dw7S8zBMTiHeAkzmyUTrvvDlVch3BvjmFZHZPiZ6meRmPTMoj3D47iEVMjFu2iAseUC/e8dW750knZkQt6FYGFp9Peq2Ge16CEDeDPL9 qlRfEODZ oPv+FSeF0r6OnzsTd3s702GiuibWT/17YC5AjtJSKz7By9QSOH+tvdYBvKzLhky6B06hg9GL5wBcZ6Joec253OAvidk0bUc5YNvnHBAtNmHsAlShlYL5Gj+bPXmSZa2vBEL82Yen0SnUtOBqUIE/heAqmp8ItvDVoB+TXG/Gc3ycmbkcJv06XQkMCZbFvn+yN16T4XJC7711I1lMDhJYLb3Sy5U0LT7HrZiHGwmxd31e/R0vFZz2MQYU/s7+T1Z3f5ObfQFgVQZD14GoOYXv3Gw7T7Ns9nSrvZKbX38DmUuU6OaZ4zBopw+hns2mtq9SspJ+ZtU54fYvHBN5zzlt1k9MwtnUTZFYZVsbJ X-Bogosity: Ham, tests=bogofilter, spamicity=0.000018, 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 Sat, Feb 01, 2025 at 11:30:24AM -0500, Gregory Price wrote: > Rather than ask whether we can make portions of the kernel more ammenable > to movable allocations, I think it's more beneficial to focus on whether > we can reduce the ZONE_NORMAL cost of ZONE_MOVABLE capacity. That seems > (to me) like the actual crux of this particular issue. We can! This is actually the topic of the talk I'm giving at FOSDEM in about 15 hours time. https://fosdem.org/2025/schedule/event/fosdem-2025-4860-shrinking-memmap/ I'm just going to run through my slides and upload them in an hour or so. My motivation isn't CXL related, but it's the sign of a good project that it solves some unrelated problems. Short version: we can halve the cost this year, halve it again in 2026 with a fairly managable amount of work, and maybe halve it a third time (for a total reduction of 7/8) with a lot more work in 2027. Further reductions beyond that are possible, but will need a lot more work. Some of that work we want to do anyway, regardless of whether the reduction in overhead from 16MB/GB to 2MB/GB is sufficient. ... or we'll discover the performance effect is negative and shelve the reduction in memmap size, having only accomplished a massive cleanup of kernel data structures. Which would be sad.