From patchwork Tue Oct 11 21:56:30 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vishal Moola X-Patchwork-Id: 13004458 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 72CF2C4332F for ; Tue, 11 Oct 2022 21:57:12 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 65AF86B0071; Tue, 11 Oct 2022 17:57:11 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 60A8A6B0073; Tue, 11 Oct 2022 17:57:11 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4D1E66B0074; Tue, 11 Oct 2022 17:57:11 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 3A7006B0071 for ; Tue, 11 Oct 2022 17:57:11 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id F0F6D140755 for ; Tue, 11 Oct 2022 21:57:10 +0000 (UTC) X-FDA: 80010029820.14.4AC4883 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf13.hostedemail.com (Postfix) with ESMTP id 5908520032 for ; Tue, 11 Oct 2022 21:57:10 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id l1so14453390pld.13 for ; Tue, 11 Oct 2022 14:57:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=+F5sfh0Rem2dK5Aa0qmcHnEwuB0gA3U54snqr1MK29I=; b=eMRmp4cYWbPP6wDBMDfsmqZB8j3L0pdXz0USSKHbljqyKpkTzQECMDjMkmaEL5BbqD d0ojSuFCVN5LlYWi0iCcIJaPY9E22F8FbUSe6/FoWxLtoz0TZHq1OdLDUdOPQbV8BvXk IYqRrFJma0+WM09dFSflg7yM4Z8l8TqWlW5xa0/IeAklzdX6mmhsd3dwi7LV+XmH43O8 WC/qUmZ2dauCdU4WSWsQWLlcVg/xCw9Qya4aUT3epUd2zQf8HDKjHwQWyBz++/rs0WXv MHUT0whOHvLxWtnvQ1n3OrLpFOtuz5e/qhDbh8/hhJxx/XFcgt6xR53Zw28rYZrRAnB5 09xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+F5sfh0Rem2dK5Aa0qmcHnEwuB0gA3U54snqr1MK29I=; b=QvEs3dnzMUt4m/UP8DkTgSILXx956DSd8gHJSN+QSmUfLNeuvqspRI5BPHYyNOQP/T MC6lmrEm3OqXVR2kJrUB0IGQMEW4iZbO4HFuaUB3RvTdPefFHiAVurT+kR9dso+Haq6h x8+eh5cFOdprdJjok0XEY3XKoPpFFpFpw/bNVoF3mtthvhDQamH86kuiehakj9r/vhxr Ld4gT8jFJuKfbItMkBVolID6GK/3y0b+tB+bbiEB+LoOjOCcT+H+w5jLdQ62JDHUR7vX KxelIv/UvQEU9LHxAeJrNt/pkyM0z8W4nmTSH4jYzUU+s5drvxqvR1NM21Oc0bHzw048 0J4g== X-Gm-Message-State: ACrzQf0XPm8N9cnW1DDrK26/yMKIok7AXmcfWmzv2fMw0v/pMwax+Q0G iRYzUXyOaEjY/OxWIUMlGGA= X-Google-Smtp-Source: AMsMyM5fnG3YqCag8hs7pwcz+qWz/Zz7bczdTMGFDfgYvFKM/b6ZOo7yErr5yJz5nx1ogvRCHmpYNQ== X-Received: by 2002:a17:902:ecc5:b0:180:a7ff:9954 with SMTP id a5-20020a170902ecc500b00180a7ff9954mr21822581plh.97.1665525429085; Tue, 11 Oct 2022 14:57:09 -0700 (PDT) Received: from vmfolio.. (c-76-102-73-225.hsd1.ca.comcast.net. [76.102.73.225]) by smtp.googlemail.com with ESMTPSA id z17-20020a170903019100b0018123556931sm6580371plg.204.2022.10.11.14.57.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 11 Oct 2022 14:57:08 -0700 (PDT) From: "Vishal Moola (Oracle)" To: akpm@linux-foundation.org Cc: willy@infradead.org, hughd@google.com, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Vishal Moola (Oracle)" Subject: [PATCH 0/4] Rework find_get_entries() and find_lock_entries() Date: Tue, 11 Oct 2022 14:56:30 -0700 Message-Id: <20221011215634.478330-1-vishal.moola@gmail.com> X-Mailer: git-send-email 2.36.1 MIME-Version: 1.0 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1665525430; a=rsa-sha256; cv=none; b=3v5DP6w/8EnKG0ltZn01TUnczlY7tq/ZeBNRT48M//tmDp/manArKmfijzuQ/HOWvbZt7A rglzn2PI24b1WVhF6uPfY/5tN9j0KeUeAhh4GV/2ovPK0xGIiYVea3YPXuy/8zqOFOgLwb pT+gifsl8Lv9C3y45Bn/4Nbk6L1azwk= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=eMRmp4cY; spf=pass (imf13.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1665525430; 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-transfer-encoding:content-transfer-encoding: in-reply-to:references:dkim-signature; bh=+F5sfh0Rem2dK5Aa0qmcHnEwuB0gA3U54snqr1MK29I=; b=HBKYD8aAQWhp6gf3zX2JB+YnIIk574m1xglP1X3AqLBAPlucX/Kj2ciFNLxNiZ8E0Qn6y5 bRol1JiA0gRrVHHPfs1UXF/ps8uVAn9G4NO1G58nRd59vmc8TYqGA+ZgIg5uEoAxhqMT23 0w1GnNurTdOEbSQJrOmcF42fQg/f24w= X-Stat-Signature: mqs7eirojpgzznbpwxs6ed5sc5bbm53a X-Rspamd-Queue-Id: 5908520032 X-Rspam-User: X-Rspamd-Server: rspam08 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b=eMRmp4cY; spf=pass (imf13.hostedemail.com: domain of vishal.moola@gmail.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=vishal.moola@gmail.com; dmarc=pass (policy=none) header.from=gmail.com X-HE-Tag: 1665525430-390610 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: Originally the callers of find_get_entries() and find_lock_entries() were keeping track of the start index themselves as they traverse the search range range. This resulted in hacky code such as in shmem_undo_range(): index = folio->index + folio_nr_pages(folio) - 1; where the - 1 is only present to stay in the right spot after incrementing index later. This sort of calculation was also being done on every folio despite not even using index later within that function. The first two patches change find_get_entries() and find_lock_entries() to calculate the new index instead of leaving it to the callers so we can avoid all these complications. Furthermore, the indices array is almost exclusively used for the calculations of index mentioned above. Now that those calculations are no longer occuring, the indices array serves no purpose aside from tracking the xarray index of a folio which is also no longer needed. Each folio already keeps track of its index and can be accessed using folio->index instead. The last 2 patches remove the indices arrays from the calling functions: truncate_inode_pages_range(), invalidate_inode_pages2_range(), invalidate_mapping_pagevec(), and shmem_undo_range(). Vishal Moola (Oracle) (4): filemap: find_lock_entries() now updates start offset filemap: find_get_entries() now updates start offset truncate: Remove indices argument from truncate_folio_batch_exceptionals() filemap: Remove indices argument from find_lock_entries() and find_get_entries() mm/filemap.c | 40 ++++++++++++++++++++++++++++----------- mm/internal.h | 8 ++++---- mm/shmem.c | 23 +++++++---------------- mm/truncate.c | 52 +++++++++++++++++++-------------------------------- 4 files changed, 59 insertions(+), 64 deletions(-)