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 BB1F2C54E49 for ; Tue, 27 Feb 2024 16:40:43 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3F4BB940015; Tue, 27 Feb 2024 11:40:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3A12F94000E; Tue, 27 Feb 2024 11:40:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2444B940015; Tue, 27 Feb 2024 11:40:43 -0500 (EST) 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 0FF0194000E for ; Tue, 27 Feb 2024 11:40:43 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id D71D8A0CA9 for ; Tue, 27 Feb 2024 16:40:42 +0000 (UTC) X-FDA: 81838147524.05.B1BBFFD Received: from out-181.mta1.migadu.com (out-181.mta1.migadu.com [95.215.58.181]) by imf13.hostedemail.com (Postfix) with ESMTP id E12472001A for ; Tue, 27 Feb 2024 16:40:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=a4qGhESs; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709052041; 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=IqGMBKnYn/QrgVfOj0WWSs+uvU9TA5U1Pary0hbDu00=; b=4npKYxo4SMqNGYtxKROb5ykKG1XK0FKBgJd2LDzZJSNw/bIE7iihD6gJ7YexHgj7ipQXm8 xL2vt2FKm69dNEM8SyoOYoR6lWUpNQyUQfKn/jFHl+1BvhEVup6uMyW6335CaBklfmf4Yx /mfu78xfk8mMeULmUd7B/blnkqYP534= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=a4qGhESs; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf13.hostedemail.com: domain of kent.overstreet@linux.dev designates 95.215.58.181 as permitted sender) smtp.mailfrom=kent.overstreet@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709052041; a=rsa-sha256; cv=none; b=1FIZtPfelWISZJzVIaXftuNzG77Di0+GxiNAZq9+TiHxwJ3BxCA9BXHLajDLQ51k63EpnM NOXJV2cFop/Q03hwCOqMeetuwPVi07vrvMryKYLBNRFt1I6+iBaLsfNBNuvIglNqdQwlwH hIYyFOKd4aV44ym1Wh8m0oJ4cgFO4ok= Date: Tue, 27 Feb 2024 11:40:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1709052039; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IqGMBKnYn/QrgVfOj0WWSs+uvU9TA5U1Pary0hbDu00=; b=a4qGhESssTTzkGy2+Uv8q68Vlj6IlrykUhxoBIAvTJM1VVVGTJgMVAIvAgMGDyCrD17PZ3 SnDSmItEjgCBn17FFW6zlPCGYFYiqFXkHtZHwRIqHObSXHImtjWI+9KJfk65F0kG9GsO9m 40Ndv+7sDZ+0dc14Pp0geccOEWac0cQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Kent Overstreet To: "Pankaj Raghav (Samsung)" Cc: Matthew Wilcox , linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, david@fromorbit.com, chandan.babu@oracle.com, akpm@linux-foundation.org, mcgrof@kernel.org, ziy@nvidia.com, hare@suse.de, djwong@kernel.org, gost.dev@samsung.com, linux-mm@kvack.org, Pankaj Raghav Subject: Re: [PATCH 03/13] filemap: align the index to mapping_min_order in the page cache Message-ID: References: <20240226094936.2677493-1-kernel@pankajraghav.com> <20240226094936.2677493-4-kernel@pankajraghav.com> <37kubwweih4zwvxzvjbhnhxunrafawdqaqggzcw6xayd6vtrfl@dllnk6n53akf> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: E12472001A X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: i87w74gboi4yy6jktgomwpahxrsmwd9q X-HE-Tag: 1709052040-313193 X-HE-Meta: U2FsdGVkX1/+0bvOW1IWG3gU3358bORWGP4H3H4HTeDXhchpVDsq6NvogQECrEu1cJgxp33695qNexG7fnHb3x4TfnWvyukt65HAwkoRfpxvYzGBhsqqCTR195F57PW24nnHF1YcZTikBAucb+zZ0zUVisps8CaT0i+PSd4y6lU6IvNiZrWvPiPriVFBsIOknvWNWp3sFN2g2Ft5lcd3bk/aVsjZz6L4YjSTEQdOxRlbxH2Ho/8jqcJy4FAtxuFNutlC+zgxSk8q4KNayRGVHHu8/Bgjn9RXb34hadNYVMNKXeomRVOE+5FPF/o4XEfTsJRgFpuOexWQCSRPExHIrl9EbuVwxLOTM1oKjl4hvHR6wB9DZWaq+/FVV7jWdP/uebeaMzHoRtiz7qvk1V9XbZmJAJkbwHXExEChcdc4IQbz9i5z5b/zsW7MD/nu0SS8zyY+WyT8r3dYlk7UPzPF6rHat2BTQZfpKVQX/SnZeUBWOh35Vr/Zt1Nk6ZyAJbs5iE2YOJHI4yODzF9Zqq5tsw2UBeil1l0NTtA2n5TRiVmyh8tNmeWE6m47remTabaVZNjzgpZm99qZEH8sNjwC+MSW57Uoe2ttHT7w0BgtFMz/oClpvhBbQEN0TbeKuhGb3QqG/Fyg7X3gwkzeVTF+k6diGXHWdCtc9q9ak0wagtG1v7S+ahPqRZZpDNfHFght0dnN7fm+Eusm4sT/QIu0FJKZbi92mL2sZpEVY4/2xCa51o1+MheeXRpY8bVwtNSpl13BBoewI29yKO0ZvG0/FsNLVvF3B4pcKwJc47QpoinWo6/pSJZuPYXINlfcGLB5Nq7Dqqu2MY+ACK8cIqmD9OyqqiINGzsl2TpBp9ZAD5zUok8cmmmfjt1pSm9uhlYmLCXwM5FCJh1hHlhEl+gzfLW8tBxhx3qA+QM24znC9FA8J2tp4oB1Pay/mVE+elcSvxFv4DcF0UpoUXx9OZX c/NZlYyO MPx2UBN9+bAf3MZboavrj0FuaS/vULmMYKOS3VKV73GEaGsoC11T2Zw4gXAjO8Xn2XVv0l49a3rOQKEgkw9p1rSNyFhjV61bKP0hWP9+BKWHepf7kWIIDW6bcwLdCWCk5ku0likFOKfAqLJNVIiuTo9x7Pt7cRzv9ec3OPe4prvR4/lmnHgJmvAQ0mPuiVyL0RA4F 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 Tue, Feb 27, 2024 at 05:36:09PM +0100, Pankaj Raghav (Samsung) wrote: > On Tue, Feb 27, 2024 at 11:22:24AM -0500, Kent Overstreet wrote: > > On Tue, Feb 27, 2024 at 11:06:37AM +0100, Pankaj Raghav (Samsung) wrote: > > > On Mon, Feb 26, 2024 at 02:40:42PM +0000, Matthew Wilcox wrote: > > > > On Mon, Feb 26, 2024 at 10:49:26AM +0100, Pankaj Raghav (Samsung) wrote: > > > > > From: Luis Chamberlain > > > > > > > > > > Supporting mapping_min_order implies that we guarantee each folio in the > > > > > page cache has at least an order of mapping_min_order. So when adding new > > > > > folios to the page cache we must ensure the index used is aligned to the > > > > > mapping_min_order as the page cache requires the index to be aligned to > > > > > the order of the folio. > > > > > > > > This seems like a remarkably complicated way of achieving: > > > > > > > > diff --git a/mm/filemap.c b/mm/filemap.c > > > > index 5603ced05fb7..36105dad4440 100644 > > > > --- a/mm/filemap.c > > > > +++ b/mm/filemap.c > > > > @@ -2427,9 +2427,11 @@ static int filemap_update_page(struct kiocb *iocb, > > > > } > > > > > > > > static int filemap_create_folio(struct file *file, > > > > - struct address_space *mapping, pgoff_t index, > > > > + struct address_space *mapping, loff_t pos, > > > > struct folio_batch *fbatch) > > > > { > > > > + pgoff_t index; > > > > + unsigned int min_order; > > > > struct folio *folio; > > > > int error; > > > > > > > > @@ -2451,6 +2453,8 @@ static int filemap_create_folio(struct file *file, > > > > * well to keep locking rules simple. > > > > */ > > > > filemap_invalidate_lock_shared(mapping); > > > > + min_order = mapping_min_folio_order(mapping); > > > > + index = (pos >> (min_order + PAGE_SHIFT)) << min_order; > > > > > > That is some cool mathfu. I will add a comment here as it might not be > > > that obvious to some people (i.e me). > > > > you guys are both wrong, just use rounddown() > > Umm, what do you mean just use rounddown? rounddown to ...? > > We need to get index that are in PAGE units but aligned to min_order > pages. > > The original patch did this: > > index = mapping_align_start_index(mapping, iocb->ki_pos >> PAGE_SHIFT); > > Which is essentially a rounddown operation (probably this is what you > are suggesting?). > > So what willy is proposing will do the same. To me, what I proposed is > less complicated but to willy it is the other way around. Ok, I just found the code for mapping_align_start_index() - it is just a round_down(). Never mind; patch looks fine (aside from perhaps some quibbling over whether the round_down()) should be done before calling readahead or within readahead; I think that might have been more what willy was keying in on)