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 83AE7C43334 for ; Tue, 28 Jun 2022 03:34:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EB38F8E0002; Mon, 27 Jun 2022 23:34:40 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E3D648E0001; Mon, 27 Jun 2022 23:34:40 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CB5C68E0002; Mon, 27 Jun 2022 23:34:40 -0400 (EDT) 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 B69C38E0001 for ; Mon, 27 Jun 2022 23:34:40 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 8ED20611D9 for ; Tue, 28 Jun 2022 03:34:40 +0000 (UTC) X-FDA: 79626227520.12.0022CB8 Received: from mail-pl1-f176.google.com (mail-pl1-f176.google.com [209.85.214.176]) by imf13.hostedemail.com (Postfix) with ESMTP id 5B03720017 for ; Tue, 28 Jun 2022 03:34:39 +0000 (UTC) Received: by mail-pl1-f176.google.com with SMTP id jh14so9921906plb.1 for ; Mon, 27 Jun 2022 20:34:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance-com.20210112.gappssmtp.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=pZ+/evlGnsJ8jD6C9tMwnqlQXDJt8JhJGnpn4OPCdjs=; b=ZKbAeK5dLgm2DXSIg5wecdROkd4oaR5bX00Hgrpx3CycC+gycPH90r8HsP89MIggwQ Tgue21oNaVdD1QixnmeuatxNcsmJG4xKnv5Gp+DxvrMF89AnWKUGEelvc0PlxtyZQ98G gRIANjbvmLyMraCLSQKxlpOsnPK+SulUvHUW7egM/R2LRJjKiT5EpDedRPJxzTVsmiol iQyxuXdUdrSqbd4vg9WhMKMZGwzXpEjFJdSGjQZIDiX08h4PJTmF0avQSLtwZfOnSyX8 OcFZz2Kc/mQjCSMoB6dKyXJXSiNEZOxcLLNhniWqQszFiShJRUMnJs8r8vqXCcFFYZFe CJ2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=pZ+/evlGnsJ8jD6C9tMwnqlQXDJt8JhJGnpn4OPCdjs=; b=MXwNgB06661xxFljlUHINzZG0hyHeKIc0YmGXnYBG9lUTl0LlGFuxKvBqCmX4jt8Pc 8mAhK5KbUvA6ALeh3gcqaOZjEJYAtrMn+fF/uimiip9z0pIWSaCxSLiZaNE2eWs1GnFY 0umikSpHcwWxHFfG+lLE4qE54u61TIclZqgoIx0uOBHkm2F5TCJ3SujK5QUBEXMz3NTa 2tbp9HM+atOlRZ9/0y8mTM4kgY1GPXnO7sbNnu+XVGiUPsJceS7DllcnJE3ih8fboPI8 xXMuKK22DC33MSl5sts9RojBesupNsLveDp+SYN/Y6b8NtAFvkSLpt+BrAw0p19BuEjb N9tQ== X-Gm-Message-State: AJIora8/EAZ0jrvECAZdN2OgL7xzRHK1vBt49oZch2iOV0eoTsuJGvsc +ZgO/jUTtjO42HyZdqlh/EfW7w== X-Google-Smtp-Source: AGRyM1uTk/gqugCXTP+8MBHLnYa3VLEn9+TuUj54C7lV4fs/Sl3H+2Kf2QtAKD6V0UZkAx7Wg9hRgg== X-Received: by 2002:a17:90b:3ece:b0:1ed:13a9:8531 with SMTP id rm14-20020a17090b3ece00b001ed13a98531mr24513558pjb.183.1656387277925; Mon, 27 Jun 2022 20:34:37 -0700 (PDT) Received: from [10.4.214.173] ([139.177.225.253]) by smtp.gmail.com with ESMTPSA id j10-20020aa78d0a000000b00522c3f34362sm8036655pfe.215.2022.06.27.20.34.32 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 27 Jun 2022 20:34:37 -0700 (PDT) Message-ID: Date: Tue, 28 Jun 2022 11:34:29 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.10.0 Subject: Re: [PATCH] mm: hugetlb: kill set_huge_swap_pte_at() Content-Language: en-US To: Matthew Wilcox Cc: mike.kravetz@oracle.com, songmuchun@bytedance.com, akpm@linux-foundation.org, catalin.marinas@arm.com, will@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org References: <20220626145717.53572-1-zhengqi.arch@bytedance.com> From: Qi Zheng In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656387280; a=rsa-sha256; cv=none; b=316fbZ9UI+Z+bc3cUtNhEtRo3GVDCySFwiuuuMPbS0dpQBO+X9Ek6aCTgWGXpmOQTSuTrk r8RToWvmo6NUSALKpSY5jvezATYU2e6b3HIHTtDySORUVRezCWwWZnmPFwA5Xc58Lz+5l6 8v1pRIPfjhXW5igJcXfQU4v/RrlDpJ4= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=ZKbAeK5d; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf13.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656387280; 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:dkim-signature; bh=pZ+/evlGnsJ8jD6C9tMwnqlQXDJt8JhJGnpn4OPCdjs=; b=BS788AteKdBY+zAaNOuPZWUD1vxx03au7aHFe+OTmGngZZSsCbkYe5SpcFIC1GfxJfkbG0 y4Ntl8o1N2GU2yC5wHZE7jm7bG2j4MQUDMQoZND/N9n/tvUC3FKlNj9em7bt+hHgUrH19D aiosz23ThscJ2JjLJxQeio1/dIcvyLg= X-Stat-Signature: hm4ffg1o1wby6618nb8odbfrrz7takk3 X-Rspam-User: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 5B03720017 Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=bytedance-com.20210112.gappssmtp.com header.s=20210112 header.b=ZKbAeK5d; dmarc=pass (policy=none) header.from=bytedance.com; spf=pass (imf13.hostedemail.com: domain of zhengqi.arch@bytedance.com designates 209.85.214.176 as permitted sender) smtp.mailfrom=zhengqi.arch@bytedance.com X-HE-Tag: 1656387279-944026 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: On 2022/6/27 22:41, Matthew Wilcox wrote: > On Sun, Jun 26, 2022 at 10:57:17PM +0800, Qi Zheng wrote: >> The commit e5251fd43007 ("mm/hugetlb: introduce set_huge_swap_pte_at() >> helper") add set_huge_swap_pte_at() to handle swap entries on >> architectures that support hugepages consisting of contiguous ptes. >> And currently the set_huge_swap_pte_at() is only overridden by arm64. > > Bleh. I hate the way we handle these currently. > >> +static inline struct folio *hugetlb_swap_entry_to_folio(swp_entry_t entry) >> +{ >> + VM_BUG_ON(!is_migration_entry(entry) && !is_hwpoison_entry(entry)); >> + >> + return page_folio(pfn_to_page(swp_offset(entry))); >> +} > > We haven't needed a pfn_to_folio() yet, but perhaps we should have one? Hi, IMO, it would be better to have a pfn_to_folio(), which can save the redundant page_folio() call in the current case. But this is not related to the current patch, maybe it can be a separate optimization patch. > > Related, how should we store migration entries for multi-order folios > in the page tables? We can either encode the individual page in > question, or we can encode the folio. Do we need to support folios > being mapped askew (ie unaligned), or will folios always be mapped > aligned? Do we currently have a scenario where we need to use skew mapped folios? Maybe it can be used in pte-mapped THP? Hmm, I have no idea. > >> + if (!pte_present(pte)) { >> + struct folio *folio; >> + >> + folio = hugetlb_swap_entry_to_folio(pte_to_swp_entry(pte)); >> + ncontig = num_contig_ptes(folio_size(folio), &pgsize); >> + >> + for (i = 0; i < ncontig; i++, ptep++) >> + set_pte_at(mm, addr, ptep, pte); >> + return; >> + } > > It seems like a shame to calculate folio_size() only to turn it into a > number of pages. Don't you want to just use: > > ncontig = folio_nr_pages(folio); We can't use folio_nr_pages() here, because for PMD_SIZE we only need one entry instead of the PTRS_PER_PTE entries returned by folio_nr_pages(). Thanks, Qi > -- Thanks, Qi