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 7CD00C83000 for ; Mon, 30 Jun 2025 04:18:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BAA186B0092; Mon, 30 Jun 2025 00:18:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id B5A066B0096; Mon, 30 Jun 2025 00:18:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A700E6B0099; Mon, 30 Jun 2025 00:18:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8EB956B0092 for ; Mon, 30 Jun 2025 00:18:13 -0400 (EDT) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id 3D94916037B for ; Mon, 30 Jun 2025 04:18:13 +0000 (UTC) X-FDA: 83610759666.11.5459994 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf21.hostedemail.com (Postfix) with ESMTP id 71D7D1C0003 for ; Mon, 30 Jun 2025 04:18:11 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1751257091; 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=ATlQtWqLhX11Y9xExPNAenJ6Iuau9lOm7QTSU8t34Nk=; b=Y5u0rIhfJN8t5gWXzIyymKupQxqvsFKm9pKd0ZBiqlv3xl9G76XDpAYG+HNmJ+LY6F0ihI hY+HVsFU1pi9+UcC2lKeVgjwxIjlXFHQ2RsDX1SjZY0EOi8Drr5w88Wpl0CRoRmAgX3TuC PZ6fOMcIKNdYtzj6W8jFmO2mjAPZYRk= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=none; spf=pass (imf21.hostedemail.com: domain of anshuman.khandual@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=anshuman.khandual@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1751257091; a=rsa-sha256; cv=none; b=z4ZhL0yFqJN3gyM2/B55yTr2lQDcgj7ktZ2+OI2Gb/yDPseksNfYANDY5vNrU5dk6pRWDA QaJ3ClkiB93D7f1ygA1Nqs/AqZnaShUMg53mURKx0+7pYhPRWx9/pwy2I9JJXNxW7OF9GG JitU241ZHoAtr+5jxuzDvB5PGcjyXWw= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3E4AD1F60; Sun, 29 Jun 2025 21:17:54 -0700 (PDT) Received: from [10.163.39.2] (unknown [10.163.39.2]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BC4BF3F58B; Sun, 29 Jun 2025 21:18:07 -0700 (PDT) Message-ID: Date: Mon, 30 Jun 2025 09:48:04 +0530 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH 1/1] mm/debug_vm_pgtable: Use a swp_entry_t input value for swap tests To: David Hildenbrand , Gerald Schaefer Cc: Andrew Morton , Matthew Wilcox , LKML , linux-mm , linux-s390@vger.kernel.org References: <20250623184321.927418-1-gerald.schaefer@linux.ibm.com> <20250623184321.927418-2-gerald.schaefer@linux.ibm.com> <9fb04185-5b71-46c0-b62c-0e0e6ee59e6e@arm.com> <20250625182846.5bce1aaf@thinkpad-T15> Content-Language: en-US From: Anshuman Khandual In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 71D7D1C0003 X-Stat-Signature: yhz7rz8f414dhd1n1coh9bp96x9tgo8u X-HE-Tag: 1751257091-809653 X-HE-Meta: U2FsdGVkX188a/ElgLRg0q5QQJAfhr2AJBfPN6zJwdbutSX+IriQk1PJBWSPNTODgnwOyOddI0xix2DEPn2SJXPCgK8nhkgOI7R68BIdwP0VDSB46LByT89Hl79vI48Jr55nvnSGSpdo0o+8Wfl3nQIgWwXw9PKqOepqLFWjtjPAaePyaC86kcicnHyEolU8NU6uoMbwTunBSz6aJ0l7a9+Fpwrq5PfOkKkqJY/vDQuf+qsjM+TVxC4CKVH8+yeQMLAkoqBJUF5ha0ZAjoBGj64sb2KEGuLxO3X4IhcQY1o8DqpSEusFqS8tfd7HNhHtklFH4PoQoglYL1xDDFmyeAmT5rUb2mdeCKhueIaibNHmBCXULSbcQAQjzrcUGCjGC73+fHCra+HiM3RBbKacrbMnzBq2fwuBut02hNodpwJsQFoySa123vkjk14xlAY/C6aW1QvxdNRmB5IOAE6O3zVsS/UG+u+Mp5MJJ4REJ1yMiqWsbjFTWQbd9BHSqo6RU269gA0IlnvW1RUcE/TZHlP6N7vpeFs3s9D+pN1fL5zBKytCs4qco/cr1acPUn/OTnwn7oFyOg/nSoZjcUG/cnATG60PvrlVFiRaS69CY7Kc4xg0p5iD8h8x6c+k9NSPx3N4SkfwsiEe0L4YittWppN4hhehkRt64AzlTqNBVQEKBCWFATHDZgbuaVgKdQQS/AlmPjnp+AK3oKEetI54e8C+pBf3WWuIXAYNiiRmWAu7Oa5PvNMW4TBQZ8dzsMgzZg6rLgG/3UpxDj2h/I1lyCoKPK/Dmh5Ka9ZwpXoPK1u/txhykb10TCQTTkqQPK0e7kRJDKoN9zJ7XV5yDk4xF82m+I9ogXFyrRzasIXf+yqo96qweVl83O/bx67Pk2txlFNVumz2sTxbsj5kS5rWFtwW71cxzXS9UA2udUfUcnvT98T/xv6/HnAAdTC6BfMTwVc3xHtnEns2WK8hJeQ kCVlclVR 3h/OOCqJKS/Oy7VZMTLcptX50+eqmG0Dm2o890PXjcUPgW/iqtbkgV6rQN7nPisk+R7RlDdo8nrDW5HlbGcY6p1riwkm/P4EJvbfQrNVRiv9l5Z2QzgMsI/SXCjiXF61aTx+APVdMuXSx57rntmsn0LTkr93lOrKxmUZIq91qy1MxcGM= 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 25/06/25 10:17 PM, David Hildenbrand wrote: >> [...] >>>> @@ -1166,6 +1173,7 @@ static void __init init_fixed_pfns(struct pgtable_debug_args *args) >>>>     static int __init init_args(struct pgtable_debug_args *args) >>>>   { >>>> +    unsigned long max_swap_offset; >>>>       struct page *page = NULL; >>>>       int ret = 0; >>>>   @@ -1248,6 +1256,11 @@ static int __init init_args(struct pgtable_debug_args *args) >>>>         init_fixed_pfns(args); >>>>   +    /* See generic_max_swapfile_size(): probe the maximum offset */ >>>> +    max_swap_offset = swp_offset(pte_to_swp_entry(swp_entry_to_pte(swp_entry(0, ~0UL)))); >>> Why not directly use generic_max_swapfile_size() which is doing exact same thing. >>> >>> unsigned long generic_max_swapfile_size(void) >>> { >>>     return swp_offset(pte_to_swp_entry( >>>             swp_entry_to_pte(swp_entry(0, ~0UL)))) + 1; >>> } >> >> Good question. I just moved this code here from pte_swap_exclusive_tests(), >> see above, and did not think about that. Now I also wonder why >> generic_max_swapfile_size() wasn't used before. >> >> But it is not exactly the same thing, there is an extra "+ 1" there. >> Maybe that is the reason, but I don't really understand the details / >> difference, and therefore would not want to change it. >> >> David, do you remember why you didn't use generic_max_swapfile_size() >> in your pte_swap_exclusive_tests()? > > Excellent question. If only I would remember :) > > generic_max_swapfile_size() resides in mm/swapfile.c, which is only around with CONFIG_SWAP. > > It makes sense to have that function only if there are ... actual swapfiles. > > These checks here are independent of CONFIG_SWAP (at least in theory -- for migration entries etc we don't need CONFIG_SWAP), and we simply want to construct a swap PTE with all possible bits set. After this modification of PMD based swap test - there will be now two uses for generic_max_swapfile_size(). Rather than refactoring these into a similar helper in mm/debug_vm_pgtable.c - should the existing helper just be moved outside of CONFIG_SWAP, thus making it available in general ?