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 17882CD5BCD for ; Tue, 19 Sep 2023 15:01:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 93BDA6B0554; Tue, 19 Sep 2023 11:01:32 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8EBC76B0556; Tue, 19 Sep 2023 11:01:32 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7B4726B0557; Tue, 19 Sep 2023 11:01:32 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6DA736B0554 for ; Tue, 19 Sep 2023 11:01:32 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id C4EE040D4B for ; Tue, 19 Sep 2023 15:01:31 +0000 (UTC) X-FDA: 81253660782.28.067E523 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf01.hostedemail.com (Postfix) with ESMTP id 2F1154003C for ; Tue, 19 Sep 2023 15:01:26 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vV7xzhXL; dmarc=none; spf=none (imf01.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=1695135687; a=rsa-sha256; cv=none; b=oZvh1n3rfXJDnfiTws/efwqoGBhgsvIRqfcGZYtm3z41khMRWSbmkEPkj5n1gz+L1Dkzsz F/lJRtglzpNqZRyUYwZ4IrV3Zxd76cpzYx4r6SAEpnu9jdBtHizI9TNq5LeqeLa3hFd4/6 gHY+4K7RHklKzano8qLHXZSnILHWAx0= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=vV7xzhXL; dmarc=none; spf=none (imf01.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=1695135687; 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:in-reply-to:references:references:dkim-signature; bh=Rtc3uem8ddiR9Ja2IfzYS5WR/DSCeWUeDjOJFAPqtE8=; b=uY4bz6WQcoTnev9MQ3in85W2EAkpYIkeNL4xrdezfMwk8Os3845gtrBkMssX1cA3iXlVgs kvf1sKTmlV6YV3VL1KTsLwJC+VvC4fuDwPNElCuAMEdy9ZzcEZ/RyNAIBFTkKrVhu9GAme mb39tUXnhmvE3Ybksyxyg53Yhbd3mkQ= 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=Rtc3uem8ddiR9Ja2IfzYS5WR/DSCeWUeDjOJFAPqtE8=; b=vV7xzhXLw4nmH7SNWv9DHWcrC/ LlKLNp1Ua8UIgPvSuVGmmwt5P/Lpg6rk9yv1OSI+AINScnm40sviBiE+8TIJfpc/RzWk4TWv3bZc1 DsXCBCLTMcdQPNdhVrDCPJxszKpFwMDtX2mdHv6m88tvH5SamsV9a4jQ6DVDm8/cpRzKmMSCa9pSV 4zSaxFjFziPh+BYX+TWbVN9sn/v35CaUKuYjC4uTSyJ9Y6y/zNqaO6KjVcoGw9qPiIMW23OLVwk7/ F0l/OQWHeh8z5zWlNQW5IT6UdISh7oBL11c7j8ZYgTsL/NgXKaTsijZQDKf3CA31dkllARhW3G+Fg Hp06KLzQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1qicE3-000GGV-5J; Tue, 19 Sep 2023 15:01:19 +0000 Date: Tue, 19 Sep 2023 16:01:19 +0100 From: Matthew Wilcox To: Daniel Gomez Cc: "minchan@kernel.org" , "senozhatsky@chromium.org" , "axboe@kernel.dk" , "djwong@kernel.org" , "hughd@google.com" , "akpm@linux-foundation.org" , "mcgrof@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-block@vger.kernel.org" , "linux-xfs@vger.kernel.org" , "linux-fsdevel@vger.kernel.org" , "linux-mm@kvack.org" , "gost.dev@samsung.com" , Pankaj Raghav Subject: Re: [PATCH v2 6/6] shmem: add large folios support to the write path Message-ID: References: <20230919135536.2165715-1-da.gomez@samsung.com> <20230919135536.2165715-7-da.gomez@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230919135536.2165715-7-da.gomez@samsung.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 2F1154003C X-Stat-Signature: s4wt4rd3b1kpt56exnuir66sqxke4hh8 X-HE-Tag: 1695135686-862230 X-HE-Meta: U2FsdGVkX19NYH4w67N2vlBR8nlrcqs6ZA6h2oej6mmnSJg6JFuP+OvHL9sELfmQROBXiwgNvkLapRgNe2CZHAxETMtvF4jp2GSyCXQPpnP59KvhwbPaahBJunNvexz0zl+QrV3ZOzcUC0lyFBMwLuyuUcgDO3/UNvz0I811c4KckaWvCwC4MjS5HWZppZKveQn6+EInhcM1onv50URHk8CXPPuXtk3lnA43UC7FZMMTsNTR1fAyMhlca/UjPwGPXCSrFrP0v1HpAoyaFsMN2wIvNUWtDYswgd2S98ssYQP5m2NginltO3s3eubN3H4RyApV302mYOEXMD0r+cgrVmU/WtcLZaQhVVSRmxq4xKTCKUCl5pxXKtlR7LsAF9UzMXSlQUwfIv+EH56xNiNOa2YUwyT2teTqruyH3tTaEkIOYGzJQy8K2q5yLIzZW0X9HF0BWmSLwnT7sayMhjQAJ+xN13LqZysDg6XJp3LK2L/PRphOS09W7kXjZ8CK7y+f2nNjef3PUnxxEjuQcq2jrTN9rU/bawhNLAufFpMSalNhPqp7PD7dXeHGTsCgE9+pwAk2oBzhOH85/GSy23aHUvzndKNaVqc0GOKJFI6OWtrj3SGy9foU72MXonwCpT7Zen3LPlA2ocJCVrJkpUdKzKBsHXnPS0CEML4/3WDv6b8sX5LdD6895BFqOUGrEE12xjjhi01AdYcYpQfT5a0MpyHJE9ICCfFWc/mC1jkKULFz40GONx+bsPY74JMCuopVKyFEXKn6nJxlbirOYIeVobEJQQsxz98BUIjMenQgy6cmVLROtR7Vjp+qRRXo1DlyN0Yf1dnNe9S0daL95fO9tyeQQlNgWsvjN1vwOa3EVRgCPmLiVDcmzZSj9OqLEl4NgyZdBvfNSxFeD9jHsim1d34Veb87c8OjiIT6y6y+P93KeQ4PVI18YynXe0OrOVXxI5XidnZVSxXdoBi96pi /MSg2FA6 T6ZkefekUb9jCo8tMD7/aQml0IymIBjWrq8jJGqM9gUR4p0xDmm76h3/1+tEM9P9B8tjukHSUw96nT9x6ST3KiLQZK5a4UmDoGW6lW7kU9OGHNTqglJ3Vekxj019juR3nvR4B5cKJAHqShXK6bVI/uup/iNhBcYDyB6AV1wG+pCqGOSfEbX1naEqTvg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Tue, Sep 19, 2023 at 01:55:54PM +0000, Daniel Gomez wrote: > Add large folio support for shmem write path matching the same high > order preference mechanism used for iomap buffered IO path as used in > __filemap_get_folio() with a difference on the max order permitted > (being PMD_ORDER-1) to respect the huge mount option when large folio > is supported. I'm strongly opposed to "respecting the huge mount option". We're determining the best order to use for the folios. Artificially limiting the size because the sysadmin read an article from 2005 that said to use this option is STUPID. > else > - folio = shmem_alloc_folio(gfp, info, index, *order); > + folio = shmem_alloc_folio(gfp, info, index, order); Why did you introduce it as *order, only to change it back to order in this patch? It feels like you just fixed up patch 6 rather than percolating the changes all the way back to where they should have been done. This makes the reviewer's life hard.