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 E17EAC46CD2 for ; Wed, 24 Jan 2024 17:51:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 79F526B007D; Wed, 24 Jan 2024 12:51:06 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 74F4D6B0082; Wed, 24 Jan 2024 12:51:06 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 666156B0087; Wed, 24 Jan 2024 12:51:06 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 566156B007D for ; Wed, 24 Jan 2024 12:51:06 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id EB89640370 for ; Wed, 24 Jan 2024 17:51:05 +0000 (UTC) X-FDA: 81714945690.13.19E5437 Received: from gentwo.org (gentwo.org [62.72.0.81]) by imf07.hostedemail.com (Postfix) with ESMTP id 366A040011 for ; Wed, 24 Jan 2024 17:51:03 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; spf=softfail (imf07.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706118664; a=rsa-sha256; cv=none; b=WY8FUVekr9ULiTtbHkaAAx3xwmPtjeT3AATBXIj9ZunACyLuSefGn3CmwMi74ipPX0pb8b CZJfpznz17Q+W7vyH1qVgmYGmVA6gQqVebHgnPW6BC7ZIdcRNlF2z4jtb637x/GqBokk9Q vq2rDtIr45j+2z+B8wALirnB3Uo7By4= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; spf=softfail (imf07.hostedemail.com: 62.72.0.81 is neither permitted nor denied by domain of cl@linux.com) smtp.mailfrom=cl@linux.com; dmarc=fail reason="No valid SPF, No valid DKIM" header.from=linux.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706118664; 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=5j45GbGnu5wmpEwE/qeCWOFbiMDqrmOQZ+In2X9KLC0=; b=K7DAVts5o0KQjekr63B2Iq0HkPgBDxfh9wMeVE+u97WfMrNv8KCfCsiv6ukG1DJIqMsoOV ORq+AtRa8BgQOI/dYDJ7IhHe1cmVuWyBeecqMcSClGa5XJ+9WmsARq6QuYbMGBNozTADiS m9OrBsCifVx8y8EG6d+4dP28ZR6LNRU= Received: by gentwo.org (Postfix, from userid 1003) id 854D340A94; Wed, 24 Jan 2024 09:51:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by gentwo.org (Postfix) with ESMTP id 838C840787; Wed, 24 Jan 2024 09:51:02 -0800 (PST) Date: Wed, 24 Jan 2024 09:51:02 -0800 (PST) From: "Christoph Lameter (Ampere)" To: Matthew Wilcox cc: David Rientjes , Pasha Tatashin , Sourav Panda , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org, linux-nvme@lists.infradead.org, bpf@vger.kernel.org Subject: Re: [LSF/MM/BPF TOPIC] State Of The Page In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 366A040011 X-Stat-Signature: 35qefphx4wgctxcwt4juyr5tqyy4t9wt X-HE-Tag: 1706118663-755096 X-HE-Meta: U2FsdGVkX18TtQGd6OsuWsIj7JqC+MVblOCAmgWLx4cv1z/IWbu4zRJyUCRHB8DKCLyZ9GjZkDp9fXVw1pjTeNWiENp7sCaqBoJKENlmikkfDeTFdYVRspWwlOcH1h7COvQ4PhyW+o8qgP4QHyBDy4sLYEi8dYpliOW2+SjJtnavmvqq1l46uRZfCMjUGpJjGcKCi4aMbtrmJQsW2s/cDw99ks3iMRy2JM+MMdPwmFzQ8AwaK+8rlN2vi5NwrQxDqqpgoimOPXugwZvmYUG1phxREmxVX+ker4/iAEb1eg/wgSjnYFlUqiDFoSWV6DsSmufIrFOrhiKmMoF5RWXcIQbrQW4jjkk1L6QWGtxM8ZgbT+37Po6+tb+M9E4bBPYKsRIk2wQH971UsuRadNK7NNA9bh1OplCGHNQVi/tmE/9kKxUKrBHQHYi65PQ0j38AXl5daKBlAnk6Ae7RhcDzWVulng+QtmP+khsgfPYxIA504Jraufd9XFU1sk855uYyUF2mao8+x4s0ZKKESVFccCPZlfc9CBxWmLaxOJoisU8OAZrDy7ioqjfnE6RupSOoh3q9WUg3KAQh5ee+Zg9zVPRBj42V5kvC3fmSrfTLgEkXY5x7a0ZKybtxPuTPJhKQcpeG2qzM+XMqucjtFUjcIuB8uk9sZLLHakNQZ3oR7jfvymcAKO+vqiTKk3jUVPoUwodI3Vam1sYwXjXaeofkoFHhIcWtccJyduonrCGG05InSu65kQr8HNIgsTHwtTEm2uQin45D8BSunfGCz9g8Vj6+qE8JxdFbdJbhZdH9oTVaQH7iGDtm9sVsotewiPcsFBE41yN3J+EfomSFFM4ErWdN5AoLf1mWhYv09CbhNMuDRZwykXIMjOYzgVQuL3wJzfUa2FlefCY9Ux0xjtY7vs276pe21EsP5bpRqnqGEW4WZ2QMviY+BM5gZGkS9DyRx3ck15GusYW4j9yf4i9 tPhOXHqK UIqIGdZPGmZ3mni+K4QwQRM1dMvcPB9x97sWXO0Syz4wzr8rNcBqWqmTPmciMcTipyjJ9yqCz5Zwg6ay1lu3WQrFNxumvt/u/uei1 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 Sun, 21 Jan 2024, Matthew Wilcox wrote: > > I'd like to keep this topic relevant to as many people as possible. > I can add a proposal for a topic on both the PCP and Buddy allocators > (I have a series of Thoughts on how the PCP allocator works in a memdesc > world that I haven't written down & sent out yet). Well the PCP cache's (I would not call it an allocator) intent is to provide cache hot / tlb hot pages. In some ways this is like the SLAB/SLUB situation. I.e. lists of objects vs. service objects that are locally related. Can we come up with a design that uses a huge page (or some arbitrary page size) and the breaks out portions of the large page? That way potentially TLB use can be reduced (multiple sections of a large page use the same TLB) and defragmentation occurs because allocs and frees focus on a selection of large memory sections. This is rougly equivalent to a per cpu page (folio?) in SLUB where cache hot objects can be served from a single memory section and also freed back without too much interaction with higher level more expensive components of the allocator.