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 044BAC46CD2 for ; Wed, 24 Jan 2024 21:03:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5EC756B0092; Wed, 24 Jan 2024 16:03:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 573ED6B0093; Wed, 24 Jan 2024 16:03:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 415EB6B0099; Wed, 24 Jan 2024 16:03:51 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 207DD6B0092 for ; Wed, 24 Jan 2024 16:03:51 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id DD7B71A0CE8 for ; Wed, 24 Jan 2024 21:03:50 +0000 (UTC) X-FDA: 81715431420.07.9B8B703 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf18.hostedemail.com (Postfix) with ESMTP id 2234A1C0005 for ; Wed, 24 Jan 2024 21:03:46 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=un1TlhdF; spf=none (imf18.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=1706130229; 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=433rk6984ZwH1fKWqetVZtMnQr+cS7uCBdOXgsXCWks=; b=O/b0XvlVPCxzbohk/HM6Hr8L4/RbtGw6d0iTSLzitfYdVl1SKl6MdBhY1hnwJGHUnS+PjS 3wkcaTLvdILrti5plXSYK+wfAghUM5xmkbdk4vK7App7bmo7FNRjgJ/eC1p5dAetQfzMqm 37OebyK3vMvTEPG6LMZpqx2wytWMJBM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706130229; a=rsa-sha256; cv=none; b=D4A20UV9CX7w8miHzueM4NeDygdCdAuL/NwxRtMgtevVUylGIN5iJgVVlqMHP8rvhDSyjD h2kfStVqNNw47/PSfL36g1w8yD5wwAZPkM4pG2iH7avs7JPMI2KxBXjK5j84AiI9YUyXBh ZcAZhRD7Ss0RA+t+2QwAAkD62TxexDU= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=un1TlhdF; spf=none (imf18.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=433rk6984ZwH1fKWqetVZtMnQr+cS7uCBdOXgsXCWks=; b=un1TlhdFKnzRIKZ86ouo8CTE6J NRhLshhgBxNLygumQSTPNA3g84SH81bTm0Nz/t62DUurTnQWAplUXSNQDIThruyLD2jzpakM4rBnL FjxUyjvUdQQbi7T5UZuqKES7aXT3rmgEWxooDdzxDawmoYMQKFR1/1cFo3NCo7jEke2rSXBoukp3Z AqRIB3YTicex0csNpUkuUi6sSo37HNnRnKGIPJxSQKzgin1h9j3c6GrkxMn/JNSGVh59YwsgoRWkR sYxXuCmrOuC+w30NDDuDzYrY7C15ECqPhhB8XnT5fzn7lBkeT55qR/d4YLuAIFUDDvPGxrvtx/kz2 yC4lcskw==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rSkPQ-00000007mOj-38zQ; Wed, 24 Jan 2024 21:03:44 +0000 Date: Wed, 24 Jan 2024 21:03:44 +0000 From: Matthew Wilcox To: "Christoph Lameter (Ampere)" Cc: linux-mm@kvack.org Subject: Re: Project: Improving the PCP allocator Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 2234A1C0005 X-Rspam-User: X-Stat-Signature: cj589asttiww1p68k3x83ijf63stxcwd X-Rspamd-Server: rspam03 X-HE-Tag: 1706130226-58846 X-HE-Meta: U2FsdGVkX1+mbHNuRaMaML93qQ+RT4R0TIVzNCz1MxnprIdc84LCXBiIJDOV8d1crINBUWU+Ik7bFh2aY1UTkEsKv8Jqj5r/EFJge/NoK+vXiMF6wUu1vRZ+1/OxPEeurOWct6aAdOGlw5TwRRgp4G0OFSXmdJ+clvgyBF9a0E9tvBbXeqoP0xxitR3K5+Vn2IWRQC21ZguF62HoHlucJJclZ4STE7+oEZRc8MZbBIEujBMa56CDtg4gdnRutwNNLZ4Qmy1aI4Cl9rpITJki/SZkWTV1fTQMlv2G3T7chvrRFAi0zFJumpwrbzn0RNEcf2CsIIaVYTrDK7iq7HpCqVTTn0a5Q+GH1tBu8qbFZGtghnKcUsCe7KrrZ6/kZ/7+huF7pV4wglGew9kv8frgp/MmTpYu4pD8pVXLBiPcqMMWXFzUA2NHd3Fc7D1S/cWnvaEjIm5jbOG3s7Eviug/FS/Ybu2rGFLHhrayD8d3e3f/ZK6iGy7Un8N7OsANaypPJ3t5e69jG5h0ndTvGWvMBI1kMCsycSSKzXz0+Wc6tIiubJVU9gRbPJLYICgKxscoU7PYw5cuPB4R2aNbHaIlUpNcs4fe6rIAzRuSkFzM+wSZ9zg+ZZ2ZRuU8DlJ48bEIEeGBJzNDii4cJpXGVEPaMQP7u+Bx8GVwEtvuU/65q0sDA+jH7OlfvF2UYU2qCiNWrUXa1VwdOiITFh/3fOg/LlG/b1UCjs5d/5Vnc4GaFlOLJc/lRZGlx0wROTJqlNb47QmJke3glbrQQQ47VDhLpZs2LJylg+5+6LpL4TQNCaHKj0hZ+4ypZIF14K5+jcWuV+40H0nODbN6sWnSSG3N23wdV9+6LlHTMTW6KJjV3E2aiheFDlllH3pw/eXDrxYG5GVcXhbaDvueTnm5loe6BaJE4vOdiP0JVsFwsOGPJRmcoTXekwDti3ClxOwenoAdKXf4qSg4NEsSQRN2NXc Qqmck553 Fg3RtSGKiofN3G/jM4JN6GWr+OdfYKLLJX+cmNGR9zawCFOoqfckT/vAaMvm8Ipsxdt6IPzxLrUyJZ+3jbnYG3YYZt8pO70p8LR7KG3Eh399h5b3piSDLhdDIkNFWYe2kCt7e 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, Jan 24, 2024 at 11:18:24AM -0800, Christoph Lameter (Ampere) wrote: > On Mon, 22 Jan 2024, Matthew Wilcox wrote: > > > When we have memdescs, allocating a folio from the buddy is a two step > > process. First we allocate the struct folio from slab, then we ask the > > buddy allocator for 2^n pages, each of which gets its memdesc set to > > point to this folio. It'll be similar for other memory descriptors, > > but let's keep it simple and just talk about folios for now. > > I need to catch up on memdescs. One of the key issues may be fragmentation > that occurs during alloc / free of folios of different sizes. A lot of what we have now is opportunistic. We'll use larger allocations if they're readily available, and if not we'll fall back (and also kick kswapd to try to free up some memory). This is fine for the current purposes, but may be less fine for the people who want to support large LBA devices. I don't think it'll be a problem as they should be able to allocate more memory that is large enough, just by evicting memory from the page cache that comes from the same device (so is by definition large enough). > Maybe we could use an approach similar to what the slab allocator uses to > defrag. Allocate larger folios/pages and then break out sub > folios/sizes/components until the page is full and recycle any frees of > components in that page before going to the next large page. It's certainly something we could do, but then we're back to setting up the compound page again, and the idea was to avoid doing that. So really this is a competing idea, not a complementary idea.