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 C0CC8CEBF6B for ; Fri, 27 Sep 2024 02:13:06 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2D9146B00A4; Thu, 26 Sep 2024 22:13:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 261448D0003; Thu, 26 Sep 2024 22:13:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1014A8D0001; Thu, 26 Sep 2024 22:13:06 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id E202C6B00A4 for ; Thu, 26 Sep 2024 22:13:05 -0400 (EDT) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8846580874 for ; Fri, 27 Sep 2024 02:13:05 +0000 (UTC) X-FDA: 82608895530.02.F74C8B8 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) by imf21.hostedemail.com (Postfix) with ESMTP id 6C6D61C0007 for ; Fri, 27 Sep 2024 02:12:59 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=aUFm21s4; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf21.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727403165; a=rsa-sha256; cv=none; b=NQENKSSOEGtTWGXYN0IKGEOn0j3UMKxrhABkugMVcHesLXRezooHgMJDcgZhvFG98cBtt9 UjnZCpTu4qf6MGthf4kh9YUHC0xPcqkm25IXVuFIbJk482Xi5W2edk9F5jhsf68SHxSlTj JMbnex77oxWJgHLcUY2ejCjc2OzUAms= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=linux.alibaba.com header.s=default header.b=aUFm21s4; dmarc=pass (policy=none) header.from=linux.alibaba.com; spf=pass (imf21.hostedemail.com: domain of baolin.wang@linux.alibaba.com designates 115.124.30.101 as permitted sender) smtp.mailfrom=baolin.wang@linux.alibaba.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727403165; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6CSk17LOoyrQJbMjqeRVf9PJcXpLPrzQR/pZZ3UyV4E=; b=orEgT6ROarrva/DnT0iEovPsS7vY1aqxVmNwMoXkPhDhJC1ek+WYz0tfohB3jYYbIkfuEZ bfpN8Sqh9b8ZelmB6Ipfjt/hr9I9eE03QuZNON3jmEuxku8c2+Ds+y95OQWoPuRqp1Rb3R coBZuTu8b66jFD96C/Yb6dl+VF7dlUQ= DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1727403170; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type; bh=6CSk17LOoyrQJbMjqeRVf9PJcXpLPrzQR/pZZ3UyV4E=; b=aUFm21s4o4sYksQtbbPaF+SfED9O04f0wc1qe1LWBlBHCrg09HJqwtB7uUNZmrIjfV8zuWtpyOBm71EbpQmFzRZDUfNF5c1lVxXdQhuF3n26x7haS7FnURt0lobaWERnrD6pFPTt08nSFQZq2BNSa4lXKDFkqHM/2aYBtBTPIsE= Received: from 30.74.144.105(mailfrom:baolin.wang@linux.alibaba.com fp:SMTPD_---0WFooIys_1727403168) by smtp.aliyun-inc.com; Fri, 27 Sep 2024 10:12:49 +0800 Message-ID: <9011b7cd-f6a9-4cd9-a80d-7536df1c6a60@linux.alibaba.com> Date: Fri, 27 Sep 2024 10:12:48 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v2 1/2] mm: shmem: add large folio support to the write and fallocate paths To: Matthew Wilcox , Daniel Gomez Cc: akpm@linux-foundation.org, hughd@google.com, david@redhat.com, wangkefeng.wang@huawei.com, 21cnbao@gmail.com, ryan.roberts@arm.com, ioworker0@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <18532bd8-08bd-4494-a3af-fe252a803380@samsung.com> From: Baolin Wang In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: taadewcwnt6ffd4dw8pyr451eyzwdzsc X-Rspamd-Queue-Id: 6C6D61C0007 X-Rspamd-Server: rspam02 X-HE-Tag: 1727403179-379414 X-HE-Meta: U2FsdGVkX1/MUrkv2OS/4+sISw3MgR/D6HhTRFh+I+R0UIBvYgxOtL/cmaiTmnEwTQThA0TxGUGFhuGH1XbrB+esZ0NjstdxQkCHq0UhJI56y+tAKeE9O00BYC4kSVnwX5Yd0jyzlFOGEFdX0cJ7Jv3J50sUvlT8atYpxvQ4kce7c9ZzKa8x9A7evWsjt/0umS1cDQFolB9IpVJAIJJvveBb/s1eQM3hWVxEmGCFBOUefaR+USfQW4qsfEnEFQihXxJ5xKkFnrjblapE+zAS/xMky/3DBLjiMFYaLAORKwHoJ6oZPUP4+zBwHKjZpdcZx3KyNRKdbuZM0GQR2pj/hEkC/Vuhi/bv8MmMgFKfVuai9WiZYo7evuEQf/hnj5Bsx2dfft6eiGiDDPe3mdKW8U7g3+TdRqHu75hUnrCiKKna/6HGf2zlgIQ7yYPbEfxnXDZz1yGbU+0sntrmK/KFCS65H3cgXtpRhuD+gW4vg3IJfDtAmPg/El+HG1uUeNCBH+HcFoJ+ZX2/DJZipHnRA2oGjRkfKOZF1aLNcyEIu771CRCeoTNde28lyUS6pmLBHnRq0gp8oBk0UgoYZTC0j1K05gtXTHTlDV9jaavvEDAvQ87KumHoDxOUXP7OF66NVN+yzehWb68UJ5fm+2vNBdO/1ZPZ2uv2WpWhGdUzL7r9eW+QR95t/MwFztcH8pTlPWavuH/zazrf0qPG48QJihzdhhOa4sySy5T449Iks+XX7mhV3tfTLGfbaTuVjovpCEiHEf6FSWN4IK8ElhsNhQeQsLy4Ph3AbloIBVq+o9zN1YMKTDrYREPk/lwswmPDBHcxIb2JQxUcN5CwnXlLdYbtv0Gkz+HIn4kujoyNKTuxPmqH4s0duvkm5nf/R96KxY62+D4g3aC5glDfv0FI2bnSDbUnbINQ07KwrEM4o81buG4xz+O7JzBe5qJcGvrYU/HuOE4I6GzTgy6h/L1 0xTIbMls Wl/WXd8NCd58gV6Dop3aik12ksLJ9WJVTzWt6IZtcbrYeGQnTcduSy+ZHAb0Yj4QFwp3cV1WszrEAvfNy2mvF4Twv/AeO45+H4cw6F9miQo5IRoOkEy5DeFO3QGIkjc+wb2yU7ubbv6+YoOVPxPsVQJt/yg0qa8N3Mpm15ZV5L/Xbn99H+kCuLwcqOfYghY1AowHXtQN1iYQmj4WiX1vE0Mshpn5+l1gYILcQ/Ues2jrPgJa4d9xVl2d/ayULHXrkFOwP X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 2024/9/26 21:40, Matthew Wilcox wrote: > On Thu, Sep 26, 2024 at 02:58:31PM +0200, Daniel Gomez wrote: >> On 9/26/2024 2:16 PM, Matthew Wilcox wrote: >>> On Thu, Sep 26, 2024 at 04:27:26PM +0800, Baolin Wang wrote: >>>> +static inline unsigned int >>>> +shmem_mapping_size_order(struct address_space *mapping, pgoff_t index, size_t size) >>>> +{ >>>> + unsigned int order = get_order(max_t(size_t, size, PAGE_SIZE)); >>> >>> Why introduce the max_t() call here? Did nobody read the documentation >>> or implementation for get_order() before writing this patch? >> >> get_order() result is undefined if the size is 0. I've used max_t() here to >> avoid that case. Perhaps should we prevent that case before getting here? > > Surely we've handled a length-0 write before we get here? > >> I think one of my earlier attemps was to use fgf_set_order + FGF_GET_ORDER() >> as in iomap. But the solution taken there was to share code between shmem >> and filemap and that wasn't considered a good idea. Shall we just replicate >> iomap_get_folio()? Or else, what do you suggest here? > > We could move three of the four lines from fgf_set_order() into a > new function and call it from both fgf_set_order() and shmem? Sounds good. How about the following changes? Do you have a perferred name for the new helper? Thanks. diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h index d9c7edb6422b..ce418acd2737 100644 --- a/include/linux/pagemap.h +++ b/include/linux/pagemap.h @@ -629,6 +629,16 @@ typedef unsigned int __bitwise fgf_t; #define FGP_WRITEBEGIN (FGP_LOCK | FGP_WRITE | FGP_CREAT | FGP_STABLE) +static inline unsigned int filemap_get_order(size_t size) +{ + unsigned int shift = ilog2(size); + + if (shift <= PAGE_SHIFT) + return 0; + + return shift - PAGE_SHIFT; +} + /** * fgf_set_order - Encode a length in the fgf_t flags. * @size: The suggested size of the folio to create. @@ -642,11 +652,11 @@ typedef unsigned int __bitwise fgf_t; */ static inline fgf_t fgf_set_order(size_t size) { - unsigned int shift = ilog2(size); + unsigned int order = filemap_get_order(size); - if (shift <= PAGE_SHIFT) + if (!order) return 0; - return (__force fgf_t)((shift - PAGE_SHIFT) << 26); + return (__force fgf_t)(order << 26); } void *filemap_get_entry(struct address_space *mapping, pgoff_t index);