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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id EBA47EB64DA for ; Fri, 7 Jul 2023 13:12:43 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=eb0EALhKYWo3U5Y9OZjSEx/m0nMIfdj9Lm2R4KAMS9k=; b=UYVrHZN6K5Nf27 gs70FYujoeRf3vVZae9HB7S5hf4uxdkUsB5GE6JHiDe4yLUW4pqSWYKwdtDbWi99W5h/PCaG7/afB yB1VeI2F8bXNTBhW4hGr4JYkCSsV1feS1Qvnks8SwbglOx1kFgtZU4Zml8yZXIY9sI322LdM3+eqm Mi9kc0M9l/4Iez81fD0jstQch0xcTn5ZzMB+/P3QsgX5X2TACT0uhFBm4r/vfAJ3Ym1rVVV73HORX YEs1SAzB/VhpTAW/ieqqBgPtXWn+NybMIZbWldaDQcfsm4/8C9+rD+WhIjsNCQV/y3XtMrDUCGRUP vmCLFv4bVyptl5jYnSlw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qHlFq-004hik-1a; Fri, 07 Jul 2023 13:12:10 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1qHlFo-004hiK-2q for linux-arm-kernel@bombadil.infradead.org; Fri, 07 Jul 2023 13:12:08 +0000 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=wFqH+7Ljt87dhV27Wcx4gWglYgjDuLdi+M0sLgvzXk4=; b=nAYdwiUTj5N+C2ndcrXIOg0NzR WgxCiFOP2iVzT08YnZ2DvkdKCcsuzkmwLFNZyNSRpRI8+WvxQlC9WBYmP44C+6AGeVqjql77XetW3 stIXD8X2JRK8P1VBm98RpEWHXhV5VosQB5Jmp/Bj24p5Q8HsLIWls2YhnQ/zaECn92lZGEYyzbMkV c7I7WPtCQ+QQGIQBT0bvqSTcGvjYXgSXSTcLMC+97NqXFtyneSoi+IKhdyvw0JkysOHYAYJPirPg5 Jy3ZsbWiifnqtPL+dfpsjtd0mPjbFoq53nlpAJeX/+dzpASGKox4pRSYzjifqPNyX5XiVQlcGhA+j MPL5FXAA==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qHlFi-00C2ig-1Z; Fri, 07 Jul 2023 13:12:02 +0000 Date: Fri, 7 Jul 2023 14:12:01 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Ryan Roberts , Andrew Morton , "Kirill A. Shutemov" , Yin Fengwei , Yu Zhao , Catalin Marinas , Will Deacon , Anshuman Khandual , Yang Shi , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2 0/5] variable-order, large folios for anonymous memory Message-ID: References: <20230703135330.1865927-1-ryan.roberts@arm.com> <78159ed0-a233-9afb-712f-2df1a4858b22@redhat.com> <4d4c45a2-0037-71de-b182-f516fee07e67@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Fri, Jul 07, 2023 at 01:40:53PM +0200, David Hildenbrand wrote: > On 06.07.23 10:02, Ryan Roberts wrote: > But can you comment on the page migration part (IOW did you try it already)? > > For example, memory hotunplug, CMA, MCE handling, compaction all rely on > page migration of something that was allocated using GFP_MOVABLE to actually > work. > > Compaction seems to skip any higher-order folios, but the question is if the > udnerlying migration itself works. > > If it already works: great! If not, this really has to be tackled early, > because otherwise we'll be breaking the GFP_MOVABLE semantics. I have looked at this a bit. _Migration_ should be fine. _Compaction_ is not. If you look at a function like folio_migrate_mapping(), it all seems appropriately folio-ised. There might be something in there that is slightly wrong, but that would just be a bug to fix, not a huge architectural problem. The problem comes in the callers of migrate_pages(). They pass a new_folio_t callback. alloc_migration_target() is the usual one passed and as far as I can tell is fine. I've seen no problems reported with it. compaction_alloc() is a disaster, and I don't know how to fix it. The compaction code has its own allocator which is populated with order-0 folios. How it populates that freelist is awful ... see split_map_pages() > Is swapping working as expected? zswap? Suboptimally. Swap will split folios in order to swap them. Somebody needs to fix that, but it should work. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel