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 A283AEB64DA for ; Wed, 5 Jul 2023 12:09:32 +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=AXEyjuH1Qt5i49K4HIkFBnnvvpZAOQYNuxVW4NZVYLs=; b=tzArMYXHL4ov7L e1za8QarC4V2TkoHDz39d2UqZB4pN7SyZDeIbk0OWVfKNAsbgePQaLRwzSBQ8R+PjRtZVobkD3ihE NioqmAKAdKjwEWSLpWziHHpbAq56JQtpgcjIOW86k2RJ965CKic3MTCGVupfNiZvaDrZKrkoBzeUk t6Iybm2n9gHcx4ri4DdQJOGtgPg0ILaalpKlD+DwYDIQHEyHmourAb02qMHbdwCg6J7zt+AyIPIe+ 7AhGc69kxrZNKiodkar7l+T63NwdOq0zWAS9Raw67IWfL5lvnGMSVWQB5RYWbN2gnmTqbyZog67X6 X+59HF009/OqqKK6TsYA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1qH1JW-00Fp8U-1R; Wed, 05 Jul 2023 12:08:54 +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 1qH1JU-00Fp7o-14 for linux-arm-kernel@bombadil.infradead.org; Wed, 05 Jul 2023 12:08:52 +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=Cy83JkJmnxLA9dztdWd+Q9yw3dWpEbujYErrO2HQQ3o=; b=p8H82thFSahW225r9+3bsg9+R5 khUwiWnFyk2vYVOOTaW0KJfGwFKhQkIjgGcoYqH0MYWj3FUEFP6wWostiKFkLL3KEvGtB7JYad/av h94oZ+uHVAVAGo49iRthhgQbKA6PR8dcvOoc5d2oUr2TOcnyAq1LO6kdWU+n5MvZ5dXy0PUTY8mc3 3gDzy7inaTP8oV3LAgZBl0VKKV2EcIQPCdlwF7lyQ/vU82wWLtiGAq8Fe7r6nOjczFL8AgG9C+ymJ GphtZwLoao0kPsDakcWlY9+L9UQCnBYIpHAvdfRpBHPaQx+C72MDReHs8ulba5SmrG5OdgyKeszNW leg0mZ5g==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qH1JQ-00A3K5-Hy; Wed, 05 Jul 2023 12:08:48 +0000 Date: Wed, 5 Jul 2023 13:08:48 +0100 From: Matthew Wilcox To: Ryan Roberts Cc: "Yin, Fengwei" , Andrew Morton , "Kirill A. Shutemov" , David Hildenbrand , 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> <6865a59e-9e40-282d-c434-b7c757388b65@intel.com> <4ee6e325-30ea-f74c-7d73-10a5d1453d01@arm.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <4ee6e325-30ea-f74c-7d73-10a5d1453d01@arm.com> 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 Wed, Jul 05, 2023 at 10:54:30AM +0100, Ryan Roberts wrote: > On 05/07/2023 00:57, Matthew Wilcox wrote: > > The confusing thing is that we have counters for the number of THP > > allocated (and number of THP mapped), and for those we always use > > PMD-size folios. > > OK fair point. I really don't have a strong opinion on the name - I changed it > from LARGE_ANON_FOLIO because Yu was suggesting it should be tied to THP. So I'm > happy to change it back to LARGE_ANON_FOLIO (or something else) if that's the > concensus. But I expect I'll end up in a game of ping-pong. So I'm going to keep > this name for now and focus on converging the actual implementation to something > that is agreeable. Once we are there, we can argue about the name. I didn't see Yu arguing for changing the name of the config options, just having far fewer of them. > > If we must have a config option, then this is ANON_LARGE_FOLIOS. > > > > But why do we need a config option? We don't have one for the > > page cache, and we're better off for it. Yes, it depends on > > CONFIG_TRANSPARENT_HUGEPAGE today, but that's more of an accidental > > heritage, and it'd be great to do away with that dependency eventually. > > > > Hardware support isn't needed. Large folios benefit us from a software > > point of view. if we need a chicken bit, we can edit the source code > > to not create anon folios larger than order 0. > > >From my PoV it's about managing risk; there are currently parts of the mm that > will interact poorly with large pte-mapped folios (madvise, compaction, ...). We > want to incrementally fix that stuff, but until it's all fixed, we can't deploy > this as always-on. Further down the line when things are more complete and there > is more test coverage, we could remove the Kconfig or default it to enabled. We have to fix those places with the bad interactions, not merge a Kconfig option that lets you turn it on to experiment. That's how you get a bad reputation and advice to disable a config option. We had that for years with CONFIG_TRANSPARENT_HUGEPAGE; people tried it out early on, found the performance problems, and all these years later we still have articles being published that say to turn it off. By all means, we can have a golden patchset that we all agree is the one to use for finding problems, and we can merge the pre-enabling work "We don't have large anonymous folios yet, but when we do, this will need to iterate over each page in the folio". _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel