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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A9896C001B0 for ; Fri, 7 Jul 2023 13:57:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231967AbjGGN5V (ORCPT ); Fri, 7 Jul 2023 09:57:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35510 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229743AbjGGN5S (ORCPT ); Fri, 7 Jul 2023 09:57:18 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id EAF6D2108 for ; Fri, 7 Jul 2023 06:57:16 -0700 (PDT) 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=HOf6zW5tc2OKxnAzSW57DuGvsKKY4Rg1phen8HORVkg=; b=FvDn4P7ZEkpDde4hXJ6KlSS65n qjtlEYVIgCZChVeO1xO1TkXR7vBC6bACZqnbipoRMtKJ9g0TMvX9mOifU97HiUEbMUEKqDcPuO8Le hbeKWeuc/h+WmVaWlIWVnrwGCi/iCQiVLhVsqVePC2qVVZhMLTyZ2t7U3ffROIF7xWdehjZfYi/rN X7tDupOHB9wubZV29RZwWFXzbVbJho/j4gqFO+Pw1McbL2iBgG/gIe9iFMceyQ2jeV+IumaSGDqXc xaL4AzgCqzZJ9biTQ0ep69tneAw8Rieie8MWJkYiJwY8dwXAKbo3IuhH+5N7LAFxGsLRQfqY+WEBM 6khm6D6Q==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qHlxE-00C4Ty-SF; Fri, 07 Jul 2023 13:57:00 +0000 Date: Fri, 7 Jul 2023 14:57:00 +0100 From: Matthew Wilcox To: David Hildenbrand Cc: Ryan Roberts , "Huang, Ying" , 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 4/5] mm: FLEXIBLE_THP for improved performance Message-ID: References: <20230703135330.1865927-1-ryan.roberts@arm.com> <20230703135330.1865927-5-ryan.roberts@arm.com> <87edlkgnfa.fsf@yhuang6-desk2.ccr.corp.intel.com> <44e60630-5e9d-c8df-ab79-cb0767de680e@arm.com> <524bacd2-4a47-2b8b-6685-c46e31a01631@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <524bacd2-4a47-2b8b-6685-c46e31a01631@redhat.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 07, 2023 at 01:29:02PM +0200, David Hildenbrand wrote: > On 07.07.23 11:52, Ryan Roberts wrote: > > On 07/07/2023 09:01, Huang, Ying wrote: > > > Although we can use smaller page order for FLEXIBLE_THP, it's hard to > > > avoid internal fragmentation completely. So, I think that finally we > > > will need to provide a mechanism for the users to opt out, e.g., > > > something like "always madvise never" via > > > /sys/kernel/mm/transparent_hugepage/enabled. I'm not sure whether it's > > > a good idea to reuse the existing interface of THP. > > > > I wouldn't want to tie this to the existing interface, simply because that > > implies that we would want to follow the "always" and "madvise" advice too; That > > means that on a thp=madvise system (which is certainly the case for android and > > other client systems) we would have to disable large anon folios for VMAs that > > haven't explicitly opted in. That breaks the intention that this should be an > > invisible performance boost. I think it's important to set the policy for use of > > It will never ever be a completely invisible performance boost, just like > ordinary THP. > > Using the exact same existing toggle is the right thing to do. If someone > specify "never" or "madvise", then do exactly that. > > It might make sense to have more modes or additional toggles, but > "madvise=never" means no memory waste. I hate the existing mechanisms. They are an abdication of our responsibility, and an attempt to blame the user (be it the sysadmin or the programmer) of our code for using it wrongly. We should not replicate this mistake. Our code should be auto-tuning. I posted a long, detailed outline here: https://lore.kernel.org/linux-mm/Y%2FU8bQd15aUO97vS@casper.infradead.org/ > I remember I raised it already in the past, but you *absolutely* have to > respect the MADV_NOHUGEPAGE flag. There is user space out there (for > example, userfaultfd) that doesn't want the kernel to populate any > additional page tables. So if you have to respect that already, then also > respect MADV_HUGEPAGE, simple. Possibly having uffd enabled on a VMA should disable using large folios, I can get behind that. But the notion that userspace knows what it's doing ... hahaha. Just ignore the madvise flags. Userspace doesn't know what it's doing.