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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 81EBDC63705 for ; Thu, 8 Dec 2022 08:53:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230000AbiLHIx4 (ORCPT ); Thu, 8 Dec 2022 03:53:56 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229951AbiLHIxz (ORCPT ); Thu, 8 Dec 2022 03:53:55 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5771053EC4 for ; Thu, 8 Dec 2022 00:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1670489582; h=from:from: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=WtVANh0eBS7cuUnAJkHyLAHfwCxkRrG12+slAtG+/Kc=; b=OLICTvYRAWvZClShRUAIwD9mWbKVNaKMOB8J9S+fnVKvTFPyAa8mca61v0jvrn2pNrgplw esCvIowYvc4M7IljieXbhfyoYPG0fxXHUWHmOSSvNGmbG8YL1adq+9tzuEJbcudSURHbnV lVWjNrKKcKHlaIIMUGRrq/NaSERw2FE= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-47-NK0PoCtBPqGi6i4A9ey71g-1; Thu, 08 Dec 2022 03:53:01 -0500 X-MC-Unique: NK0PoCtBPqGi6i4A9ey71g-1 Received: by mail-wm1-f72.google.com with SMTP id f20-20020a7bc8d4000000b003d1cda5bd6fso349005wml.9 for ; Thu, 08 Dec 2022 00:53:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:subject:organization:from :references:cc:to:content-language:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WtVANh0eBS7cuUnAJkHyLAHfwCxkRrG12+slAtG+/Kc=; b=1zBGNtjbcs4qqxbBwIWJ8RgjBL2zAWGv22FpJQpx4ZKJc+E+2yXx8VAVYc6p58g0PM Eey+d6adIBewv5zTc8nIweBqEXvx+wIY/HGQrlR1DevTbjwkjA/0ZoFbQraCvfCN+FL7 Baay+szWutpd1tTm9HhxlDuUaK2y/b/V+RZSiVtIgc2KQQaq5wrCXgNkTKuk/E5PUywi MXg11mRcha9cUKLJnUtAGruKnvhQ6AtiYvRxxT3iUSD7Ar1J3wzDkQqnBc+WGYaCM7XV lhMoTlMchsEmc7OpzPIww31pZkzIHRAB0ExNNIR5uJbdjwqDKcHU+L4qSF+41TmeMdKY HQSw== X-Gm-Message-State: ANoB5pmdI7ySVzVjCl5ESNXRTxq+wXeIf87eSlsnGEvfgBGEX6/spUvm MqnZkQv0Cnn5kuCfdD50vme1KrXzL33rCZqjlqrc4USimwRhKw5FW+TX7ivB4w+4Namw1odHiXL 8Z0f2PDkpnq2Ifk4bCkYtaw== X-Received: by 2002:a7b:c3d3:0:b0:3d1:cec6:75a8 with SMTP id t19-20020a7bc3d3000000b003d1cec675a8mr10610862wmj.206.1670489580100; Thu, 08 Dec 2022 00:53:00 -0800 (PST) X-Google-Smtp-Source: AA0mqf43lyCBCnse73L4nmQgwKX2lVPb0zDtRkTV00eD7UM2rHA9mTsLvJ7fK1IaCMRkleIpPTdzzg== X-Received: by 2002:a7b:c3d3:0:b0:3d1:cec6:75a8 with SMTP id t19-20020a7bc3d3000000b003d1cec675a8mr10610851wmj.206.1670489579743; Thu, 08 Dec 2022 00:52:59 -0800 (PST) Received: from ?IPV6:2a09:80c0:192:0:5dac:bf3d:c41:c3e7? ([2a09:80c0:192:0:5dac:bf3d:c41:c3e7]) by smtp.gmail.com with ESMTPSA id h1-20020a05600c350100b003a2f2bb72d5sm5810986wmq.45.2022.12.08.00.52.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 08 Dec 2022 00:52:59 -0800 (PST) Message-ID: <0b5b1303-8bcb-c19d-5f63-0e4a3517fea5@redhat.com> Date: Thu, 8 Dec 2022 09:52:57 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.0 Content-Language: en-US To: Christophe Leroy , "linux-kernel@vger.kernel.org" Cc: Andrew Morton , Hugh Dickins , John Hubbard , Jason Gunthorpe , Mike Rapoport , Yang Shi , Vlastimil Babka , Nadav Amit , Andrea Arcangeli , Peter Xu , "linux-mm@kvack.org" , "x86@kernel.org" , "linux-alpha@vger.kernel.org" , "linux-snps-arc@lists.infradead.org" , "linux-arm-kernel@lists.infradead.org" , "linux-csky@vger.kernel.org" , "linux-hexagon@vger.kernel.org" , "linux-ia64@vger.kernel.org" , "loongarch@lists.linux.dev" , "linux-m68k@lists.linux-m68k.org" , "linux-mips@vger.kernel.org" , "openrisc@lists.librecores.org" , "linux-parisc@vger.kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "linux-riscv@lists.infradead.org" , "linux-s390@vger.kernel.org" , "linux-sh@vger.kernel.org" , "sparclinux@vger.kernel.org" , "linux-um@lists.infradead.org" , "linux-xtensa@linux-xtensa.org" , Michael Ellerman , Nicholas Piggin References: <20221206144730.163732-1-david@redhat.com> <20221206144730.163732-18-david@redhat.com> <8be167b6-3836-25c3-9f69-b8b3916ee5b4@csgroup.eu> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH mm-unstable RFC 17/26] powerpc/mm: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE on 32bit book3s In-Reply-To: <8be167b6-3836-25c3-9f69-b8b3916ee5b4@csgroup.eu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-s390@vger.kernel.org On 07.12.22 14:55, Christophe Leroy wrote: > > > Le 06/12/2022 à 15:47, David Hildenbrand a écrit : >> We already implemented support for 64bit book3s in commit bff9beaa2e80 >> ("powerpc/pgtable: support __HAVE_ARCH_PTE_SWP_EXCLUSIVE for book3s") >> >> Let's support __HAVE_ARCH_PTE_SWP_EXCLUSIVE also in 32bit by reusing yet >> unused LSB 2 / MSB 29. There seems to be no real reason why that bit cannot >> be used, and reusing it avoids having to steal one bit from the swap >> offset. >> >> While at it, mask the type in __swp_entry(). >> >> Cc: Michael Ellerman >> Cc: Nicholas Piggin >> Cc: Christophe Leroy >> Signed-off-by: David Hildenbrand >> --- >> arch/powerpc/include/asm/book3s/32/pgtable.h | 38 +++++++++++++++++--- >> 1 file changed, 33 insertions(+), 5 deletions(-) >> >> diff --git a/arch/powerpc/include/asm/book3s/32/pgtable.h b/arch/powerpc/include/asm/book3s/32/pgtable.h >> index 75823f39e042..8107835b38c1 100644 >> --- a/arch/powerpc/include/asm/book3s/32/pgtable.h >> +++ b/arch/powerpc/include/asm/book3s/32/pgtable.h >> @@ -42,6 +42,9 @@ >> #define _PMD_PRESENT_MASK (PAGE_MASK) >> #define _PMD_BAD (~PAGE_MASK) >> >> +/* We borrow the _PAGE_USER bit to store the exclusive marker in swap PTEs. */ >> +#define _PAGE_SWP_EXCLUSIVE _PAGE_USER >> + >> /* And here we include common definitions */ >> >> #define _PAGE_KERNEL_RO 0 >> @@ -363,17 +366,42 @@ static inline void __ptep_set_access_flags(struct vm_area_struct *vma, >> #define pmd_page(pmd) pfn_to_page(pmd_pfn(pmd)) >> >> /* >> - * Encode and decode a swap entry. >> - * Note that the bits we use in a PTE for representing a swap entry >> - * must not include the _PAGE_PRESENT bit or the _PAGE_HASHPTE bit (if used). >> - * -- paulus >> + * Encode/decode swap entries and swap PTEs. Swap PTEs are all PTEs that >> + * are !pte_none() && !pte_present(). >> + * >> + * Format of swap PTEs (32bit PTEs): >> + * >> + * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 >> + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> + * E H P <- type --> <----------------- offset ------------------> > > That's in reversed order. _PAGE_HASHPTE is bit 30 and should be on the > right hand side. Etc ... Ugh, messed it up while converting back and forth between LSB 0 and MSB 0. /* * Format of swap PTEs (32bit PTEs): * * 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 * <----------------- offset ------------------> <- type --> E H P Now the patch description ("unused LSB 2 / MSB 29") makes sense. Thanks! Any feedback if the bit could be problematic? -- Thanks, David / dhildenb