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 5E9FDC5478C for ; Tue, 27 Feb 2024 22:10:36 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ABA1D6B00A1; Tue, 27 Feb 2024 17:10:35 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A6A4E6B00A9; Tue, 27 Feb 2024 17:10:35 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 958F36B00AC; Tue, 27 Feb 2024 17:10:35 -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 8722B6B00A1 for ; Tue, 27 Feb 2024 17:10:35 -0500 (EST) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id C60271C1002 for ; Tue, 27 Feb 2024 22:02:53 +0000 (UTC) X-FDA: 81838959426.28.EC9F3BC Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 6908B20021 for ; Tue, 27 Feb 2024 22:02:50 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HCwO6NTl; dmarc=none; 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709071370; 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: references:dkim-signature; bh=lWafdqWD6qx2nlX3aR/78K5+SqnHxhmTQIOtI6IQ394=; b=f1s2qw0pBeIH6HmRz/sx7cuLlAARBqgNSYxkTkhLXf8mJrKxGDmRGh5eug91HSkoa6W6mS zxFlRUJhkklj2WpupI1fjiTJI/p/coD6bIJUQ5z7vtUig7MDQyxl9CHlOWdArmBmVjlvfQ 6LOrlQtWI9SjTiRKhagblzvE9cAZDc8= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=HCwO6NTl; dmarc=none; 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 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709071370; a=rsa-sha256; cv=none; b=0v6ivF1ZNH1VwFr3CAMWniJ/yN85QTYjsW4+A1rTv7K3FaQh6IF1ljMztev4p5LvpxvUDm +8WkZtasL6YBZNwC1Rh3elY0B8P8s5R0WrnvMDChWBaASt7HMWhxkJsvSf97yVvxeXve2x BFb4lzLEAlmtihSud/oAJ084YaAasIM= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Type:MIME-Version:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:In-Reply-To:References; bh=lWafdqWD6qx2nlX3aR/78K5+SqnHxhmTQIOtI6IQ394=; b=HCwO6NTlw7DZx9OV0tWREN4HPm Q/HkgZVQhk0w3MzNRWZRX6jdIHzPQcrKKhuUGjR5rXkxOEIiL1ZLolYsXAHBoUjqpTq/IH1mSBQVp FvFGmmZPTnSr+RULjelcgzGVaBu3kWqqybHftqFUMqNE3mlFoZKYjtn3ulu5LuEoIxKZMHW2rQ/FU S59vwooJiRh8w4Ziah+UlqpujDP5KIa5UWR4Ke6R9RCxDWHJ7Mi/TCNxNGMQSMPJHYYZJATjTNlfq NRq57LzwrB0zyDp4Qn0wuEXDsFSWf7/raCNt16xtcHqYJjRv9Tkkc7MlomIJTzXf6VoRAybbUF/Jg gUgpBP1A==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rf5X2-00000003UPa-4Bzv; Tue, 27 Feb 2024 22:02:37 +0000 Date: Tue, 27 Feb 2024 22:02:36 +0000 From: Matthew Wilcox To: Marek Szyprowski , Michal Nazarewicz , "Aneesh Kumar K.V" , Joonsoo Kim Cc: Jianfeng Wang , linux-mm@kvack.org Subject: CMA, memdescs and folios Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspamd-Queue-Id: 6908B20021 X-Rspam-User: X-Rspamd-Server: rspam02 X-Stat-Signature: 3y4ap1hiranj1de766gxxx949ns5adyx X-HE-Tag: 1709071370-523634 X-HE-Meta: U2FsdGVkX1+4dUmNYsum/sQSZIPvmBMeL6nD81ELNTCMchLq3CnNSkeJMe/t7rLGMF532o6gSWK/F1oKBfxD5WC4Dy/SGnT+CAzpjb/lvhwOOfh0q+xA8S6kAPFmX8Cj6zkxk56O3yYHlGeta4xOuCGsGPzMM91+i+SmA5UNhXYJSAUiIDq4+GyeiNPj80/9XH56pwsNoBem+UAR0iklWSh2iL10k/QuGPMPpuLHNJPyMdjrUdvwTXbljpha4AsAyaXwG8HmFC4zHf58eEgfN5LIlhvRIvENuUWve/hu8QxzjTr6ldTWpf5FmJdRlGI3C9mjUe0E1UfgtxKTzJsAGiXBdT6VmEb9voytqf88wcBseG8n8O2DDyWJvefgJdtEvm+INioZXwlVAUh8jpwTetTYksIwKRCPT6UZVjgj5jReQFvi91fKje1jvNR6TcXUgKKGNnCGzBmsVLn73CM+cA6H0lMxs5TxcP29NBqBjPtbt2mPYNoRa0u3YKgRrLp0yGoLqg/hGW+SnzZDfpk6J/5Ax9XaTNUxf4ZckLnb+OWAWEyk4JEd6ctfjid7uSTUGxQ5g8I/bGv8b2O15k7XE8UKYb6sAOvsbHkO/XmrPGT5DGDeNlzIZL5em3l0nxVRP/GmJC1eb5y4cAcRIgfACXAyd3iIuCl4cSa7fQI0V8EfxBs8grQpbngcCHDYP5dH9cqonLk7LbGTYn2EiqPRWzuxOMNke5WRTlI2Dht0Sly9memW2KzSOlTWq6c9BwYOwqP0H9XkdUWRKCdwgO5fPVe9ZHCpIHL1Jj1AY0rhA6WZFClH3/DaPzvPwvpmWpN3PTlYGAt6KIIxkoCdxtEOOd4SWYCLpTSG4eW1wzjQYvlNlz1WOJpEBYy7vkVmq8RQqOsTvbKrzcw5Ex2UQHzaNee35u9/g7nUayPOq3ZcwDeOPmBmQ4byqFv+XzAGXJu/dk9+nD9yEDSRmIHtQmq k9kNyqUI jgSldKpwXBXfXSxBZbynHJhjNtoqvtbwFNciVNCkClTZWt/DZL/R5lKAK2h374rzOuBim63kQw4VD0T0fpPoQp46WZ8O1CiO3M75qGbRiw1dtz3N7zm4godsIK/aRyjAOPrhEepG51CXu6SALhyLU/uSxzg== 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: It may be helpful to look at https://kernelnewbies.org/MatthewWilcox/Memdescs I don't yet have a plan for what CMA should look like in the memdesc future. Partly I just don't know CMA very well. Some help would be appreciated ... First, I'm pretty sure that cma allocations are freed as a single unit; there's no intended support for "allocate 2000MB from CMA, free 500MB-1500MB, use the first 500MB for one thing and the last 500MB for something else". Right? Second, CMA doesn't actually grub around inside struct page itself, so it has no dependencies on what struct page contains. Is that true? Third, I don't see where CMA manipulates the page refcount today. Does it rely on somebody else setting the page refcount to 1 before giving the pages to CMA? Fourth, do users of CMA rely on pages being individually refcounted? Is there a reason you've never implemented an equivalent to __GFP_COMP before? --- My strawman proposal is that, in a memdesc world, the individual pages that are free within CMA get a type 0 subtype to make them readily identifiable in memory dumps. At allocation time, the caller will pass in a memdesc to manage the pages (and CMA will assign it to all the pages, just like the BuddyAllocator will). As a step towards that, we can change CMA soon to return pages which have a zero refcount. That should catch any users which rely on individual refcounts.