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 CC96DC3A5A7 for ; Thu, 8 Dec 2022 08:54:05 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230003AbiLHIyB (ORCPT ); Thu, 8 Dec 2022 03:54:01 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56970 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229769AbiLHIx5 (ORCPT ); Thu, 8 Dec 2022 03:53:57 -0500 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 4BA4D3123D 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-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-322-tX6G0gUKOgq6lF1HupHExg-1; Thu, 08 Dec 2022 03:53:01 -0500 X-MC-Unique: tX6G0gUKOgq6lF1HupHExg-1 Received: by mail-wm1-f70.google.com with SMTP id f1-20020a1cc901000000b003cf703a4f08so351617wmb.2 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=nXCee5xtME78T3F/89AoTDxYvWBTQGnVERrBY4SpWMus4y9w/zRO6KaN4ZzPcTGfpk XIioLlkzHW5PBSVWgXPLYQmkkWyuEuwp3As5SfHKfDMJkMv3RzPx2DUGiySYXnMzlMXv k9YfGOfO+Byxo/sOe/r81JzIA5CieR/qDID8O+XKvSJTd0QnjVjU0yWyr0XIJSX768+T /gaRAW3QFzk388ft0QWNa6ozxAk7b7eREmd/mC4gerEAhqDV1RTq20/cxTPehrgnm15D lGYFJaQq31wZMyZ9BHWEhRUoEFrduyES6P0fSUF8oimOCyYE8PT/BcfGSa+3bBbu13Rz gkHw== X-Gm-Message-State: ANoB5pl5ms8ywzbTy/8Vfyen2jUTsdhM0WGvlavRSPq99DwroSGU1fBa 2pVwXQtZnb3ZrTHaPdip2lT5zpSmWcMD3dt0IIgSEtqecUo4cFr4gKqist/yWpI0C4MJ41QmTkZ q64t/ddI/2+SFKyIZrduyY1SI X-Received: by 2002:a7b:c3d3:0:b0:3d1:cec6:75a8 with SMTP id t19-20020a7bc3d3000000b003d1cec675a8mr10610879wmj.206.1670489580107; 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-kernel@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