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 2BE52C3DA4A for ; Tue, 20 Aug 2024 08:34:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A82456B007B; Tue, 20 Aug 2024 04:34:21 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A32666B0082; Tue, 20 Aug 2024 04:34:21 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9212D6B0083; Tue, 20 Aug 2024 04:34:21 -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 756836B007B for ; Tue, 20 Aug 2024 04:34:21 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8D8271218B5 for ; Tue, 20 Aug 2024 08:34:20 +0000 (UTC) X-FDA: 82471961880.24.5E3C6F7 Received: from szxga02-in.huawei.com (szxga02-in.huawei.com [45.249.212.188]) by imf28.hostedemail.com (Postfix) with ESMTP id 86347C001A for ; Tue, 20 Aug 2024 08:34:16 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724142754; 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; bh=Z+7vOrL3pNR4Bp5Eny0PB3c8bkTa1teShczzA8mnNIo=; b=GXUp6FF5+9zvW0J08F7sKT+5ah9sQF8ACfTjKDqo5htxVbPuEnOTjzXuCRWPnx754tQy92 JGougf9gAwEUkv3yispPHYcFmSYtPVF0O8nb8UCltbKkhq28pMpAtQxLHVA8rfLmmLaqfY c2l1vISxOMvpNGZ9oT+MZZ8PXo4lvYE= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.188 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com; dmarc=pass (policy=quarantine) header.from=huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724142754; a=rsa-sha256; cv=none; b=EGUpIwmpezABwgZWypUtw3GOmvfvwd7KE0Vm1HAp7QidtKagLyqR2WceX3An7WNrEO9hUO HP3eB/T3l4aZins1ss/maa2N6iflpvkxFcMlEJ7ENhB35ws4DBJK+966/tv7Map7bDWmQ0 xrMpg32L1p7s+aWYLNgDJeCx3B6u1Lk= Received: from mail.maildlp.com (unknown [172.19.88.194]) by szxga02-in.huawei.com (SkyGuard) with ESMTP id 4Wp2lY6GB9zpTWY; Tue, 20 Aug 2024 16:32:41 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 96A9A140133; Tue, 20 Aug 2024 16:34:11 +0800 (CST) Received: from [10.174.177.243] (10.174.177.243) by dggpemf100008.china.huawei.com (7.185.36.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Tue, 20 Aug 2024 16:34:11 +0800 Message-ID: Date: Tue, 20 Aug 2024 16:34:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/5] mm: remove find_subpage() Content-Language: en-US To: David Hildenbrand , Andrew Morton CC: Matthew Wilcox , Alexander Viro , Sidhartha Kumar , References: <20240817095122.2460977-1-wangkefeng.wang@huawei.com> <20240817095122.2460977-2-wangkefeng.wang@huawei.com> <646f8a48-820f-40ae-bf96-7d554bf4493a@huawei.com> <73d5e928-e06d-416a-9de6-fb2d34da9095@redhat.com> From: Kefeng Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems704-chm.china.huawei.com (10.3.19.181) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 86347C001A X-Stat-Signature: ohfobqmhps898szkxm3pptb5cuq9hqji X-Rspam-User: X-HE-Tag: 1724142856-401344 X-HE-Meta: U2FsdGVkX19raQwSAunoWDJyw9Rj6in989oR+X7bXLT0MyKbXCxm4aOFByNwrlrH5zB5eoQlqqsbUHTrwFfeHwSZV3mpW+uWBTfNIOgoDrh18H9D2w3tSzsA4UBljh3fII0nbsLzsMapD1+YM0/bXVrJf1AYKs+F9T/BC2VZcc9PtgHULBY+uapK8Rp89sgnvDq2NywXapXuKN7QiYtyScYxMCCXwNlgynzaW4m970m58nbToNA3I+xjnteSOLYaPFtkZPVbADvbn70lmG3+9WLcggm/EQMJsJJsIzvdGOAJxbYlQCiFNAnUgQKxxdOtpUrypVu1FN11RqIa0sWYqwmT6ljWB0LtJIpPjHMMn/5y0piBnLFs3z2iQv6wI3MYurKXgZEwPyept/GwIsaCuc0iUAae45+h3NDiK93MqNwysnHxaTov+71Iwz3Ry3ZttMnVwsyxTsSSHlKoYmSzew1/XT9yPOTEQex30Aeks7HODZG3ktr5m892PqgdPQWQ4pmcuOrLWIyxu+ogpF11iWrjGCJb6ro/yvFkTrtRyUBPSiYgHs3+/6ofIcfGCbilZBHXIwlH4KHDbF3ovP6nuE46whZinfQy9o/fEmnbXi8dwQ+pQYPIXytqHsjP8rZBkpVJCH27f84VJvQnYf7VNZO8QUB2r2ut0gMTbU+U0jmVPiV9GI81YpxXy5hMCpqWNmwyHbee2ZZaJeHL0AsWRLbyUdX4YaczyJWUxLVbBygJQr5nbRULlU7XOzaBmliGzeVCawN+Rx5QoKDphCHzUMyhMDdhffMhLHPpCqFtb3ia/ooUweJaIToeNzAG1zKLS2p7iv3TtAFnWcfmZoKHH+DUaJIA8bEQTNe2RE3J1oQ/sHh5iVQPig78+mf3Ttv4ypRVpQCOigD+Uu/at2yBau65dJmFkFnZZlHcRqKMkeRW+VXRAwLsn2xoQ9Z2l59qrsL5QMN3dsVvLgiGGC7 sdUh3y45 z0j1HPNbdX67ahXSugV3fUmXJqk2mEK/X33yAsz/q5xorLmseY7tYGj+JGa637mKz1jREcNzjwRsGw0++nzivelK8gIDqtP166xs/9FVinsIuerB88B+mSMVpZl1iug4MWHNSN5jXozeRH4X4jCBMS+tsqp1QJQTJj9OFheX9pn/+GjG7mIKpgxtjqEQsSQHGg5mtcuocE4WXbGnEj2rHGf1WaDMcJk7Zgxa6oFLTjqCjKoWqIdQ71gNfvQ== 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/8/20 16:23, David Hildenbrand wrote: > On 20.08.24 10:22, Kefeng Wang wrote: >> >> >> On 2024/8/19 21:27, David Hildenbrand wrote: >>> On 19.08.24 13:02, Kefeng Wang wrote: >>>> >>>> >>>> On 2024/8/17 17:51, Kefeng Wang wrote: >>>>> After commit a08c7193e4f1 ("mm/filemap: remove hugetlb special casing >>>>> in filemap.c"), the find_subpage() should remove hugetlb case as the >>>>> folio_file_page(), furthermore, we could convert to use >>>>> folio_file_page() >>>>> to remove find_subpage(). >>>> >>>> There are some comments from David to the non-public send(forget to cc >>>> list), >>>> the problem of find_subpage() is not described , so adding some here, >>>> >>> >>> Thanks! >>> >>>> >>>> see commit a08c7193e4f1, >>>> >>>> --- a/include/linux/pagemap.h >>>> +++ b/include/linux/pagemap.h >>>> @@ -789,9 +789,6 @@ static inline pgoff_t folio_next_index(struct folio >>>> *folio) >>>>      */ >>>>     static inline struct page *folio_file_page(struct folio *folio, >>>> pgoff_t index) >>>>     { >>>> -       /* HugeTLBfs indexes the page cache in units of hpage_size */ >>>> -       if (folio_test_hugetlb(folio)) >>>> -               return &folio->page; >>>>            return folio_page(folio, index & (folio_nr_pages(folio) - >>>> 1)); >>>>     } >>>> >>>> It changes the granularity of ->index to the base page size rather than >>>> the huge page size, so for hugetlb, the special handling(return head >>>> page) is removed from folio_file_page(), so we need remove special >>>> hugetlb handling find_subpage() too, maybe this is a bugfix as a >>>> separate patch. >>> >>> That's the part I understand. Any caller of folio_file_page() is >>> expected to be able to deal with a hugetlb tail page after this patch. >>> >>> Now, your assumption is the callers of find_subpage() are find with a >>> tail page as well. That's the part I am not sure about, but if you think >>> all callers are fine, then please spell that out in the patch >>> description. >>> >>> Something like >>> >>> "Note that find_subpage() would never return the tail page of a hugetlb >>> folio, but folio_file_page() will return tail pages. This, however, is >>> fine because XYZ" > >>> But I am wondering if these functions here even get called for hugetlb >>> ever ... :) >>> >>> They only trigger for iov_iter_is_xarray()? >> >> Yes, the find_subpage only used under iov_iter_is_xarray(),  and >> only afs/erofs/netfs/orangefs/ceph/smb use ITER_XARRAY, no hugetlb >> involved, so we could safety drop hugetlb part in find_subpage(). > > Highlighting that in the patch description would likely be best. The > hugetlb check is essentially dead code right now ... and confuses David :) Thanks for your kindly review and helper, David :) >