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 6F8C1C433EF for ; Mon, 27 Jun 2022 14:41:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 048B38E0001; Mon, 27 Jun 2022 10:41:45 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F3A106B0072; Mon, 27 Jun 2022 10:41:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E28238E0001; Mon, 27 Jun 2022 10:41:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id D3EF66B0071 for ; Mon, 27 Jun 2022 10:41:44 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A5DDA34071 for ; Mon, 27 Jun 2022 14:41:42 +0000 (UTC) X-FDA: 79624279644.07.7E1176A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 394EF180037 for ; Mon, 27 Jun 2022 14:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=xri+uff54HOFYBvxFfiZF2KuK5hzUKaHppr36rCO3sk=; b=PN+RyByPMxfZAUHpL0gITPl4o1 /9FJkI+OREdN14XarIWYsQ3xUW+tnm3EWHp0vkRFWloHbrrd1AR50ZJ8qeN3TicoX/rB1eoH+v4/H hvyChvOb0jnjMR99xef2TOeCuiXOiLx0nDy4+9L0AC85X2hWba3MRLNcPzOL37H2hpJU3YOrXAzoH 482hvuOqw0pmwX1uy9kSmTuIXwwaJv9UsQ9hKcNXpnNr8X2+uYzuIC2Q0+F4LUbLzXlg52TQ5OKnU ne3Yubikb7JITFLM9LrzOdKAu8vtUPAkd+JLwdTAnqZM2GUi2m/LORmVR6AWX0MtBDf1lqS2npPcV 4obdxg3w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1o5pvf-00BRKk-T3; Mon, 27 Jun 2022 14:41:31 +0000 Date: Mon, 27 Jun 2022 15:41:31 +0100 From: Matthew Wilcox To: Qi Zheng 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 Subject: Re: [PATCH] mm: hugetlb: kill set_huge_swap_pte_at() Message-ID: References: <20220626145717.53572-1-zhengqi.arch@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220626145717.53572-1-zhengqi.arch@bytedance.com> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1656340902; 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=xri+uff54HOFYBvxFfiZF2KuK5hzUKaHppr36rCO3sk=; b=fT45pMkpJEt5fSlRe6JLmZ6Mc1OibuOXyD6umLh6oBL2rwi6rDYU+PcFZ43NtWb1c+nmQB tIJHXTERSJNI+qk1OEPJHJ4zn6eXeGVMSvJXcAqhHcZVCkFmN4t66WDgZ36XrDt+bsfrip tEjx5DUou5Kf4QIz5Z4QiDSqR97o6b0= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PN+RyByP; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1656340902; a=rsa-sha256; cv=none; b=wT7USzvFicF/QyVIsIl64oN/62P+gzV/2Cr5UjTaGYrLnYaRM8+Sqf/eEcJu0+nFX/1Erk nTQehPu1uEDQDEgoEO9LmNxJsZKy939KP7UAsk+WniVQCuwJg5yNYbWjXblwXmQo+3McFx P8lch1IcVsrJu8ra4uMB434nBH7PZrY= X-Rspamd-Queue-Id: 394EF180037 Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=PN+RyByP; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: uanidw93k539d68tx3q48dho43zdt38k X-HE-Tag: 1656340902-984377 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 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? 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? > + 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);