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 871DCC4829E for ; Fri, 16 Feb 2024 00:58:11 +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=4ideAWZspLS+sTDKfgMXV+EsMVQs1czqSI+X83w5I4w=; b=AfHoRQ5epNhFoU YrHN0IPXhv9+5JOp6R9HDo9a2tvyR3ArFpnrNwr9rVLViooVH0CnvuJiLR0uWsY/toFCjlLilwMQY sCxFHspzUveOwHgI+71RaicCMY+Dieo5SimftYY9CboboaGxhnC6CoVHC1p3JCh8gKDmFfy3enAda DWrYm5ZWMCLS9kIyoNwQ5mHa/8CrVgYkG40fyviegr8fslCYr19Zz7xlvnxKJ3ZcAqCzXBMihCyab k6Opqvax3FYLiz5KZINZ4gaQd5tyDvL/2gkE8co+YEg9Vlf1fq5vmdEPQZVMZGay+o8BR9ICM4mvl JYeL91k6g6LHs7BnYG3g==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1ramY7-00000000fdK-15jI; Fri, 16 Feb 2024 00:57:55 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1ramY5-00000000fd7-3IPX for linux-arm-kernel@bombadil.infradead.org; Fri, 16 Feb 2024 00:57:53 +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=Rg6keNXeCzOyvnz/qJIf0xHBc+UX5gdIdINZ7tsu7Xw=; b=NziljXAaygDB3mcdw4/YBOsBVJ Qtvp6PQFvcuaCuE+7XRi1f1qP1CSdT7T0a8NnhpZwL+ganDoDemR24/m/s7Jf+tg5xdScrWx/0gYa NbtwOtR0SurZ+1jrCln/Nz2RruCuRnDP0+272eqqrIlX3/XzJ9oOIp5PG9Da8PEjzZgRwwx00QhaD vP7sqNCStpsJgGhwm/FZD5bhUQsnY1R9YJAfBmZzFXcPLe+MBIk0tP9zGDJMrmV31yXdsiT7V7nkB dDVcGkPOMr1QU/hjbkPqz24E83cITqAbAl88P5qojIT92b0bKclYd6o1aFAzJiHRtC5opve9NGBHd 2DNZbUuQ==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1ramY3-00000003KzI-0jn6; Fri, 16 Feb 2024 00:57:51 +0000 Date: Fri, 16 Feb 2024 00:57:51 +0000 From: Matthew Wilcox To: Dave Chinner Cc: Ryan Roberts , Catalin Marinas , Will Deacon , Mark Rutland , Andrew Morton , David Hildenbrand , Barry Song <21cnbao@gmail.com>, John Hubbard , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH v2] mm/filemap: Allow arch to request folio size for exec memory Message-ID: References: <20240215154059.2863126-1-ryan.roberts@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, Feb 16, 2024 at 11:04:00AM +1100, Dave Chinner wrote: > > The reason for the low liklihood is that the current readahead algorithm > > starts with an order-2 folio and increases the folio order by 2 every > > time the readahead mark is hit. But most executable memory is faulted in > > fairly randomly and so the readahead mark is rarely hit and most > > executable folios remain order-2. > > Yup, this is a bug in the readahead code, and really has nothing to > do with executable files, mmap or the architecture. We don't want > some magic new VM_EXEC min folio size per architecture thingy to be > set - we just want readahead to do the right thing. > > Indeed, we are already adding a mapping minimum folio order > directive to the address space to allow for filesystem block sizes > greater than PAGE_SIZE. That's the generic mechanism that this > functionality requires. See here: > > https://lore.kernel.org/linux-xfs/20240213093713.1753368-5-kernel@pankajraghav.com/ > > (Probably worth reading some of the other readahead mods in that > series and the discussion because readahead needs to ensure that it > fill entire high order folios in a single IO to avoid partial folio > up-to-date states from partial reads.) > > IOWs, it seems to me that we could use this proposed generic mapping > min order functionality when mmap() is run and VM_EXEC is set to set > the min order to, say, 64kB. Then the readahead code would simply do > the right thing, as would all other reads and writes to that > mapping. > > We could trigger this in the ->mmap() method of the filesystem so > that filesysetms that can use large folios can turn it on, whilst > other filesystems remain blissfully unaware of the functionality. > Filesystems could also do smarter things here, too. eg. enable PMD > alignment for large mapped files.... We already enable PMD alignment for large mapped files (which caused some shrieking from those who believe that ASLR continues to offer worthwhile protection), commit efa7df3e3bb5. My problem with your minimum order proposal is that it would be a hard failure if we couldn't get an order-4 folio. I think we'd do better to set the ra_state parameters to 64KiB at mmap time (and I think that's better done in the MM, not in each FS) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel