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 DC4E2C3DA4A for ; Tue, 20 Aug 2024 08:22:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 4FB3E6B007B; Tue, 20 Aug 2024 04:22:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4AB3E6B0082; Tue, 20 Aug 2024 04:22:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 39A0D6B0083; Tue, 20 Aug 2024 04:22:25 -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 1B4AA6B007B for ; Tue, 20 Aug 2024 04:22:25 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 8966341901 for ; Tue, 20 Aug 2024 08:22:24 +0000 (UTC) X-FDA: 82471931808.17.9FAE602 Received: from szxga03-in.huawei.com (szxga03-in.huawei.com [45.249.212.189]) by imf29.hostedemail.com (Postfix) with ESMTP id CC468120030 for ; Tue, 20 Aug 2024 08:22:20 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf29.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1724142126; a=rsa-sha256; cv=none; b=wqKcKqSZ6ERGJVXob4EeeFLg3g6i9LHkNCvYyjCAsfQd0viz0jNVgudh/bJRU2neRlCaD9 +xLKatnyEviSP9olDMEiJGANcnWz44PfciSqwJRAHJR6aGRTZ6ooPnlRAcdqM+l9kGwvPG 4wHROK/4O21n4MyMIOaz/gyw/Gvi7/E= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; dmarc=pass (policy=quarantine) header.from=huawei.com; spf=pass (imf29.hostedemail.com: domain of wangkefeng.wang@huawei.com designates 45.249.212.189 as permitted sender) smtp.mailfrom=wangkefeng.wang@huawei.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1724142126; 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=Mm+70NkUcUD0yLoPDw9sUFnJ/weExdSIDNYG3sRNNwQ=; b=ZAwQL2cEGI7/kyxtCJmgV6bvzbIeT6S6Wr7wQXvgvXLCm4so8zFCycl5N4PHa+uyfUNibD xwtaxI6lZ3XtnjpNeYqFqYe8y5nzIGkURhipu6TLaBrnIqbJ/DBpXH88vict8WvC6OvQ5x BTj2zzALRzJGZA93FxTfm4GKGHHuoHs= Received: from mail.maildlp.com (unknown [172.19.163.174]) by szxga03-in.huawei.com (SkyGuard) with ESMTP id 4Wp2Q73N5lzQqCb; Tue, 20 Aug 2024 16:17:35 +0800 (CST) Received: from dggpemf100008.china.huawei.com (unknown [7.185.36.138]) by mail.maildlp.com (Postfix) with ESMTPS id 5B9661400FD; Tue, 20 Aug 2024 16:22:16 +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:22:15 +0800 Message-ID: Date: Tue, 20 Aug 2024 16:22:15 +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: <73d5e928-e06d-416a-9de6-fb2d34da9095@redhat.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.174.177.243] X-ClientProxiedBy: dggems703-chm.china.huawei.com (10.3.19.180) To dggpemf100008.china.huawei.com (7.185.36.138) X-Rspam-User: X-Rspamd-Queue-Id: CC468120030 X-Rspamd-Server: rspam01 X-Stat-Signature: w6wz9a66txn98k51io7osr7f13st7p96 X-HE-Tag: 1724142140-822629 X-HE-Meta: U2FsdGVkX19Ems9xEKZExPAVnVGy85gbnKZ3J+qlqY7BsHhR75hP0qNF2qHOkceBdQbz3yT89EvOzykJIjl/lNcSEr9t3KJqAdzVCKCPP4mfyqiwk0qhdezk2zNnVCvy7uJjSD/jkGpBuiZ0Q10nY4BE8kpPP/cY4tdn7oI2cQDdsqHVojs/Y9V0iwn4fWmEiKnLtZdwD0rlVW2Iia7hWpd96jJ2JrkspjPoR8hfOsL1269FpK0YnEjLqw9eVlDIW2mbpEqHB+cpuwmrrl5JINcjTNyJePMkmYacUexTKxx7oVCFvgyitYgzruvtQkKfLXPEU7Ot74p+PAkx+Obsnj+LsIG2bNzADnPUVuQozvluf+esH2VEzhAfIWFY4hwR68ci9A6L9TLTVlW9kNPNG8TtM74/MdFzW5EjxSwrCf+egvHmKtEDmMmMGcr+k47x1vgXNBtWKC4TmHcdfB7at/sDXy1/kO8hayaPi6EaxA0Ap+36QVxdp3uVWnGgmv3S14RPyAwf6LQQ56tRHu4x2Y3MlpcMCiIgFh65oBPhVBR1NvKo2er58TwVg1u55kJVSCj8gjejlFECnDf/9dQ7TJKP66lntLJ+LQa5ESSvXRoHr6rK/vE9MmaShkEFI4YA5x0Vmu97K6RJ5NHAbhrKPKdAbBWaqDr7/dkKanQHF23i7v6x8ZGVYGno1QBrvoFM/xhzLlYIrN82TU0E34vH0soVTqFVq16688ShmSiWnzp/tO4VVRv30oCjgZaFcrxAB7UZFwl+yld3nMVdjZlSclCqidQKZ8s3wovpIp/wm7PKOY3fnfCs92CITzlaBE6Y4ZjpfqpYzr9sfloxnT9ASEPYFS1vwM1vXbXOHKMDcRqDZPaSv30V++SScfSbKJoutCTX4+o5JFhAg5X/eQ1RdWfXOOZ79znsAZr/kqksDV3UaBm696le6IFlLnv1jUww2YinLoQkPwitdeSWIR3 WH+RLnr8 JZoGM6mqZSPYG7nABS249FtAVsOTf8wONaUEvDs9NR3PowCgwe3Y0XXKCU/5C0+MJ7tXVOwj8cvI21TCx5+BqJy2Rjm8wjoQpPMh4/RY9SbclLvCEosSAozbpob/QwkWDfANRIJ0M0kJwXIrYCG1WAdGFrmQZcK9B9D0Ssz8TF18hH3ZUHGUU/VpXzHZoifGbrIV6Tj5HFgJfJymNA4fqSTM3lhkVg+UTCXzUAuds+rv0bqlpEDVCXzdlyQ== 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/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(). > >> >> And after removing hugetlb handling in find_subpage(), there is >> another issue about "head + (index & (thp_nr_pages(head) - 1))", for >> hugetlb without sparsemem vmemmap, struct page is not guaranteed to be >> contiguous beyond a section, so we need to use >> >>    nth_page(head, (index & (thp_nr_pages(head) - 1)) > > Agreed. So as soon as we would unlock that code for THP, we would run > into that issue. Since no hugetlb involved, there is no issue even we drop hugetlb handling. > >> >> and in order to reduce code maintain between folio_file_page() and >> find_subpage()， just use folio_file_page() in find_subpage() to >> fix above two issue. >> >> diff --git a/include/linux/pagemap.h b/include/linux/pagemap.h >> index d9c7edb6422b..e2553e4ac3ef 100644 >> --- a/include/linux/pagemap.h >> +++ b/include/linux/pagemap.h >> @@ -866,11 +866,9 @@ static inline bool folio_contains(struct folio >> *folio, pgoff_t index) >>     */ >>    static inline struct page *find_subpage(struct page *head, pgoff_t >> index) >>    { >> -       /* HugeTLBfs wants the head page regardless */ >> -       if (PageHuge(head)) >> -               return head; >> +       struct folio *folio = (struct folio *)head; >> >> -       return head + (index & (thp_nr_pages(head) - 1)); >> +       return folio_file_page(folio); > > ^ I assume you meant "folio_file_page(folio, index);" Right. > >>    } >> >> And this will correctly handle head/tail page, correct me if I am wrong. > > Right. > > Is iov_iter_xarray() one of the things Willy mentioned is scheduled for > removal? Then I agree that looking into removing that part completely > does also sounds reasonable. > I think Willy want to remove __readahead_batch() totally, not related about iter xarray.