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 2D487CDE009 for ; Thu, 26 Sep 2024 13:40:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B86766B0096; Thu, 26 Sep 2024 09:40:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B363D6B0098; Thu, 26 Sep 2024 09:40:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A25536B0099; Thu, 26 Sep 2024 09:40:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 7D7F16B0096 for ; Thu, 26 Sep 2024 09:40:20 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 2F87AACF03 for ; Thu, 26 Sep 2024 13:40:20 +0000 (UTC) X-FDA: 82606998600.16.2F82602 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id E2B9A140010 for ; Thu, 26 Sep 2024 13:40:16 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TjsX2Bcw; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1727357955; a=rsa-sha256; cv=none; b=LL1Ajyx8lwOqpvOXbaX7pvOMLRj+AVoeF29hDaQnElTWeNmfb5MNQCJuOTqPes52EB8ejx W5oZn0SNevIy1JZu5nzRvkbJxg9UzsGpVZeEMt5NRh3khawFKPrkPyxsYmhYfZaWyKd+fA rm8KoawUcaBKpTq73Vo78Oy6y4eO9Kg= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=TjsX2Bcw; spf=none (imf09.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1727357955; 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=FxPbI0QvyMKRaRZxxEIytMMMKgGjtJHw/Q/FOqAhZqI=; b=aasv1aoxBq3jR0Bp/+0h8B+rqE/+Thpq8wVxkAd77oeYDCQfogApqYn2bZU7JU37c6++GO X6gU1qemubgIM3V7emG1Ru/27Qz+kcjNMgscDzJk5txIOZFd9vfTi4ED2sqIRVisfE/jEG YKWytpb3K/iN81M0SaI0k9uRPPkF7JU= 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=FxPbI0QvyMKRaRZxxEIytMMMKgGjtJHw/Q/FOqAhZqI=; b=TjsX2BcwwhzvBP7n//axyX50/7 06KZeafFuQVk3q2JXRrSPzSDMUaC6VCydBytx+jheTbdYUzUOSsX9tMim2mEC70E+CHDMI+uAeH0k 1pQ1HHlxmXKgzQQu/HkYuLtfJrTAC5O9fNcgW6PvDYsPgf/b3ZIy2tzLZAyrudrnauZykDSjH/FIj gPb7v8numy/sexw7C1jaSGeq6HqozTL5Bfr2NUBc9b6rUnr/yvYjrfc5jnmq7GB698/4A0gyN/rNd IX6saKYFnnn4Fvi8STePqbv2+IwlXBknKvU0uzf81snpwzoVtSTDgtTAXNA/IGGrDtI/g5DrH+011 a+Xv70xA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1stoix-00000006kkw-1gPv; Thu, 26 Sep 2024 13:40:03 +0000 Date: Thu, 26 Sep 2024 14:40:03 +0100 From: Matthew Wilcox To: Daniel Gomez Cc: Baolin Wang , 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 Subject: Re: [RFC PATCH v2 1/2] mm: shmem: add large folio support to the write and fallocate paths Message-ID: References: <18532bd8-08bd-4494-a3af-fe252a803380@samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18532bd8-08bd-4494-a3af-fe252a803380@samsung.com> X-Stat-Signature: u7yoogktk97cfg1oe89533w8t74w8m1u X-Rspamd-Queue-Id: E2B9A140010 X-Rspam-User: X-Rspamd-Server: rspam10 X-HE-Tag: 1727358016-798463 X-HE-Meta: U2FsdGVkX19l6b9zRd+o2un/i32sxgOxMvJxyg9xzhB3FkaK/FmNNepQfT7aT7J7FAZR/VGglhGIHraG0S49DexCVVWFUGu1hIIszCUGfmkc7HGXBdF0knjbqxNWm5zEJQtf+16fcUoO7vZvPbwh/xbADKFG0sGJqYU/wFAqaDml5Nyp/UENhFaJVYyC0/SBoQlMRXKNPVR76zDlSQ8QZXtp9OZw2HVZnKDKhDYDigUscOrhncrUKOwSO4XZ1MbCEpurWvTihAmC7vg3U4EBOVoNMMciGPPI0Aj3PiPqhhMi6sCfBbR3Wa09eLhyZG6mv253/n+lnKLV3lH7Hi4j9z+3Lu1VufE2qaSFeGDzEld8i93wQ9wRkG1RLdUK/alaI9v0IoqJdtQa3K2GLFyfRSl/xux3lmV/nj/JeOwa0v0SEjw8hC/qgyLug6G7TtOKCJ7dnfd6pLWRnnw2W6Mwv/kJ3XN5W/ytp79EsEZxvaJ4PMZmS7Fv5wjhORPrjyj9yXiNCu+jshPcf4UIcQK6Wrigm9mVEEq+Zl6C+/Musf1VNfDWVAnpCJBk1Rl0tq+a9vl4hwhNkNOYFozVgscXmMEVja+joeEm+v2gHhsBJluUOI9pL5pNdWx4hiNrBE5MJIlAL9g5SqrgkoTpN3EsdW+InuNA/czAO3T70en83g9hwX9OWx5t8EBAo5CbIeVkxqhkwRGbg2Q2BeTBDObvIvhRG8H9EX620P+xitRUtnCu3lANBcbap5L6sz4LytbE+uK+bKF48W9jSECVdiFytLIwUUEcBuFse40iAp8lc8Lj1jJOYbBMC/B+51bnLoNXzw/9+LxHHuz+3D4g27yFPr9eKT35Co8IdFEwmL8aJRfD5Sjr4l+sbN+NRmjCbO3sC8/5VtKpq6Jc/lSzRiGd98jeljOBT297tEPNDcciGnEqOXG7agfTOmy8y1ladLFNqEmP7dalW5dF6SZxzmy ScOzv2PL yOqoGNM65Qcdic1jtX2CajX5LP9/9bp9KwP3y0/3YoAplBtRwHNllGy0aYSfWbNHyHcomMhzFfBx4FTJH+1FymafgHoOAwkx0Vzw0PQvOJTtnH/xCzjzEOZ20cqn9J6vFzG9JNTAC79hPPKC88BRu3frtT/pPnw7bWlGBSIhmSc+B1imBLUTxjQIcrpAAy//xlrzuA2dcKAM/mXulSSscLsv+NxVzXQAgNzsiYvGczc2pcvQ= 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 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? >