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 C9695C4345F for ; Wed, 24 Apr 2024 14:43:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 36D478D0014; Wed, 24 Apr 2024 10:43:09 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F5398D0011; Wed, 24 Apr 2024 10:43:09 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1BC908D0014; Wed, 24 Apr 2024 10:43:09 -0400 (EDT) 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 F214F8D0011 for ; Wed, 24 Apr 2024 10:43:08 -0400 (EDT) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 10FB81A0FC7 for ; Wed, 24 Apr 2024 14:43:08 +0000 (UTC) X-FDA: 82044692856.19.6A61676 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id C47FA2000A for ; Wed, 24 Apr 2024 14:43:05 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BJJTQJ4e; spf=none (imf13.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=1713969786; a=rsa-sha256; cv=none; b=V+nmmarCiiLTBJToaFU901ETTZUc/2/1VMmLLrncw9TBoips7Cp7oWbpE/x5nS2wCimC63 LIUubailFfl3pxdhTY4jZHeBLiuNwc2KMVBF1TmrOHwrj/9nV2PBxqMWEcQemaHgb5MeUd XwqGSkuT4eodUIBTqdzyERMpGSI0uiI= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=BJJTQJ4e; spf=none (imf13.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=1713969786; 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=tIT14/FSb/TZi27kK/8yK71oAYcS6aD9obeho7V54dY=; b=Lm0ONJlIBFpNkgrwQnHUsdYW/u9/UFLqAqiEfQcCJegJR55kOyEDLOrE5OV+NygJ8sMxyn KDj+yOV0ZU8h/u2IkPkaWeVfia5+NqkZtjaOtu6rrraoGzUPZ1e6wnfzOuHTGa3xbzr3Ky 8iLPL0BbKF4SoFGkk7idzA2XRKvu/3k= 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=tIT14/FSb/TZi27kK/8yK71oAYcS6aD9obeho7V54dY=; b=BJJTQJ4ej/XlmoL9BR13K+QOHx G25WThYqkBK6e+x65pq0R9ZlWfs/Wgw4iRIX8DAqKiVmiBBvqZVhhNoQSy3H4AuC3rPM4m7XNc4a1 qf4tEcpJPgd2u3MChQJT+b1QJi0fzqcG/IiRdt4eHMowV7ajDz6GDv12MrLUdOC9bZeOaR32KUCER npPgWxcgZvbJ4gJIeGf708aerFCAgepcyxO/yklEhtSviWCnS3ZXbr+ZIj6pUarpD8X/L9oOaCET5 P6YxmHKXTzOrY9jc4piioH+1v1TFZn3R7OQWeKcC9tIl+eI+pdytR9+yQ5aomdggeztyvGMsocLyZ 2fJ3JTaw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rzdpu-000000015tB-0jeH; Wed, 24 Apr 2024 14:43:02 +0000 Date: Wed, 24 Apr 2024 15:43:02 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Subject: Re: [LSF/MM/BPF TOPIC] SLAB BOF Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: C47FA2000A X-Stat-Signature: ob9i9mdq1p6matytcuoc3q8pdcf91npk X-Rspam-User: X-HE-Tag: 1713969785-574838 X-HE-Meta: U2FsdGVkX1//Rnh72/i3xvtswVxLKI1BdCndQTQS4f7CSfKljhI8tiMQltXW6SxBEAOGdqI/FjdXswJ7WTRu6oOJW4avQUfzDlevZB3lthg2f5zIlFSp7viK2+kYsGcUjRAihx4JYwWDGtZuNwcO7FDMaQljrm9MiW7JrdML5Spoy3UsTS3L7j3W+NXx0rod3P/aaKvhB7crEJduZNQ3yztP/hZfgyy5/3eI5b/uEllyzuLNc98mveKu0cjl71QuGZNPJ4pXrv3GfvTmGMuPwHyrjGlMXIfH5lm07VrrrELUxsxWxeQO/Dhb2oUKHYpOyu2KfpKhgNeNZnL560DfF5B813kbShfs/LQQ96CMaR52OW9hhxgNiwtxHesB2DxNx7pUw07h0+RPd+Zdm0IcQOpZYKntvW6wIO56F+O1eRRumxyqlDH+Hy4A72AZmg+fpwDSGcKpOliMbxgLWKGFXEOBbuhbmwQ1z1cWQz6ZyaOwvIE2M9WmAmAlu4v+r1lBi9GXbpaprCKHsh6wR2yvJZDcjlqN+DrlvFob8sVyS81hTKJFWExg050+5RGw9naBoup//wgNiNi8lkvDIE2o+0coydMNz4clp9irSguUlh4f4oBlMyDD/FiWyk46QaQdKM/pIIYg5t0imT7U5mFJcDIpRkJZUPCooEwUUyK3262Vbwm0uI6jIWe5V3tahq7Gma59+eJEH7jPhmSzmZuZYCuGB9uZdm8oTZKUzSLJFEAWw9qqlXOL3N9KG9HBFiJZS7isz2FTWyoi2DPMF5vRLyAyTWv3kJAP4LNAODswSDSebAI9T96Lc7diQpsKPp+GbQtDd5vP04Ub03UrOiW+G678ayp69un8CfO+HYH6gD37v3ejQIpUntMtK34c0Tln+gwLfUqQGIVghh3Fcsc4d4zwlPRUBSewzMBAcrwW6g76BnpWrP/BEGONgyct96e2kIcNspN1Rw3qjEwUrzU WizA7prm 9X6DFcCMv3yWeP22aRhoehsASE7dGV4Oa1XXDyIfkVIshNAEyr1qhnU1PJ29UisOvNhpwktAczxgC5S0DIYEuO/O5WNX//9Yaviv7R2d/nAOWMNIhmS0XHCs3mioDJj5zqMHBquLG+/wKKFSKr7kJqt1zvKOvX8kg1iIV+RWLa5cniT9uMUYMVXbRO0TdFYdA1m+4+TbMKDh5YRsLVz7Dh5TckJtSgTSRueCv 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 Wed, Apr 24, 2024 at 02:52:41PM +0200, David Hildenbrand wrote: > Just as a side note, I would be interested into something that can easily > reclaim pages from slab in a specific physical memory area. Target use cases > are around alloc_contig_range(), memory offlining an similar. > > ... but IIUC, the barn/sheep approach wouldn't make that any easier, right? It'll make it harder, tbh, because today we track each object from its struct slab. If we want to do something like this, we need to do a few things: - Send an IPI to all CPUs to let them know they need to return their delayed-free sheaf immediately - CPUs on the node which owns the memory we're trying to reclaim also need to search their allocation sheaf for objects that we no longer want to allocate But I fear this is pointless. Unless we can get _all_ objects in the range back, we may as well get none of them. Which means we need a mechanism for asking the user of the kmem_cache to reallocate specific objects. We've looked at something like that before, most recently: https://lore.kernel.org/linux-mm/20190520054017.32299-11-tobin@kernel.org/ (you can forget about ever reclaiming from kmalloc slabs, but a real slab cache could be movable)