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 82573C64EC7 for ; Wed, 1 Mar 2023 02:05:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0637A6B0071; Tue, 28 Feb 2023 21:05:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0132D6B007B; Tue, 28 Feb 2023 21:05:20 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id DF7006B007D; Tue, 28 Feb 2023 21:05:20 -0500 (EST) 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 CD4056B0071 for ; Tue, 28 Feb 2023 21:05:20 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 9909AAB520 for ; Wed, 1 Mar 2023 02:05:20 +0000 (UTC) X-FDA: 80518687200.01.F343DF5 Received: from mailbox.box.xen0n.name (mail.xen0n.name [115.28.160.31]) by imf09.hostedemail.com (Postfix) with ESMTP id 28A82140005 for ; Wed, 1 Mar 2023 02:05:15 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=xen0n.name header.s=mail header.b="CL8D43/P"; spf=pass (imf09.hostedemail.com: domain of kernel@xen0n.name designates 115.28.160.31 as permitted sender) smtp.mailfrom=kernel@xen0n.name; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677636317; a=rsa-sha256; cv=none; b=nbDXWPX6R28MC7AnUUopiRm/7ZTMQhAwa1VVDrtmPAghSCaGZLsmM6bmROH7l0O90SqC2Y c+iBNqNyYcc3nOKk6v16l2XYkEDVa9QuhtsWqxcZtZe4XIFXMl27FkkebD4xDvKQd/sc3G iloHoCQNaTg8qKb9VxVZZ3NvzAA9vHc= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=xen0n.name header.s=mail header.b="CL8D43/P"; spf=pass (imf09.hostedemail.com: domain of kernel@xen0n.name designates 115.28.160.31 as permitted sender) smtp.mailfrom=kernel@xen0n.name; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677636317; 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=XjGUXNCJSZMOSJuNpY01ky1MHLI+AavDR3QQ1ILc75o=; b=luMhD4xl6enx6CjdeKMMkUmLqOmazl+tPSGn5/GADSN/77pDeZScybxd9glftzwDPzDZuD N9l4nqU5BKJYDm8eNMtjaz+j27+y14gI/C73rXJEL3g0AAxBUvI914Pv7aRF8FfrmQcRvp Kh/yGGyxP0RC9MjseN6jnSHmhB5tRZc= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xen0n.name; s=mail; t=1677636295; bh=Uo15ING92T44epF0XvfiEFF/VdpfwGmZMh2j1FZp090=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=CL8D43/PuZwHtZQiCJinQkzRL8BThzHOVpu7cim8WvbyVZ4isJ63P4oGI/nZMl3sY r1uhmpUBG1YdYcdogvYOf/To3SzD0QL/HIyxsDH2cvVDhyflzy5dg6hOwmvvaq9h1/ N77+7pST+RksLMc2SYvnxc9EBrEp89LV64V98SLo= Received: from [192.168.9.172] (unknown [114.93.192.93]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mailbox.box.xen0n.name (Postfix) with ESMTPSA id 17334600D4; Wed, 1 Mar 2023 10:04:55 +0800 (CST) Message-ID: <277cd2a7-9550-2ed6-1b66-a2e6612a2565@xen0n.name> Date: Wed, 1 Mar 2023 10:04:54 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [PATCH v3 12/34] loongarch: Implement the new page table range API Content-Language: en-US To: "Matthew Wilcox (Oracle)" , linux-mm@kvack.org, linux-arch@vger.kernel.org Cc: linux-kernel@vger.kernel.org, Huacai Chen , loongarch@lists.linux.dev References: <20230228213738.272178-1-willy@infradead.org> <20230228213738.272178-13-willy@infradead.org> From: WANG Xuerui In-Reply-To: <20230228213738.272178-13-willy@infradead.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 28A82140005 X-Rspamd-Server: rspam01 X-Stat-Signature: mycy9w5j8oqsiysodgjdzgjs14qdm15y X-HE-Tag: 1677636315-41443 X-HE-Meta: U2FsdGVkX1+Q/IbDyv6DVIKp83AmG5o4ODyXsB4wevJur55DSv2xVabU4USjuUIwusdDREzuCFb841rCC+ARNx+XcUZdO8Z+aWb2LgQjPH8RIG9ZNEjQA3AigcCl91vNNKHIGmCd6XTYJ6fKmlFRUj0t3w9wPohHMXy0XTu1kPL2wKIYeVOwjYfi2FoIYvIUaPmSKrkJHhuMDVHbYkZCTwYFEMgkIPvGI5iRR55iaYhsxn1xfibogh7dMTzDv+SSzoNEw2B0Nr7BbCPT7PulaXc2CtCtiTSiZ8sAxPsepbIW5zzh45/4PuuoO59ioaDdLW4Ra36IA6lOLz0QKLgPdHS2MhLDP5mq6grVKsbqcqW5cFJ55CwUyTqir+OXsIOc9q1WS0bdKFRDeKJcXMQDDrqVy6fjJGGv4LUteyV/aFcCQh/OItBgAmbzZ+DWIMxbQ6gJYboSq/DRYL+aYyMXwoXxBMu1Qz4DIJXsYW+L6tyEFYkbMfGnzELmnmdyEgbnGY18DhtLOUTnu1pxxAl7Tf7J5auABDaYl9hDqLyJcudhSJYvws8CtZ2BBZW3Ek5z9Zudz8PRFXO4c62HkMPUnWG7pl2b7eCH21m6wxCayWzzltbLO2M/vQHnaXPjpiGqWr4LTQBEnFNGcAmaevavVTiE6OLiVukkoilaoNxoUz7aK7vvqnAFEA0odOfZmmyFsk5XPW7epeCq1M7zXQ9FhmtIrVmKEALACT5VLgRDmpO+LoxsNgAwgPZ+UYvBDwN6nYlKAQikL/Y5usWswpTMiKuYIDlC96fOcXGMlpfL1l8Ycf47Q4lZrgNYJYYrW7bUhw3Ph7xlyT4H5WMSiLGVx4n9O4Yt8BzZMmep/pMzDY/CljGd8IAEB53e+h8+pN4DkBAZyhM74tpoYvi7lHhVm1nJCMicrvzM+4TjLWG2wneOHHIcBtDCElQraUth4pj0Opr4EHvwj6awQMJ4mS0 B3tZT7/F QoJ0Ia0+cf+Zd4hRuYjxaS/XKDluf7kzDfrVSSyfzD86K67GI5QUUYW+prEn9mh6RqKRIwps76Yf05mcwbBpYS3dFaHHBHukLH4PGfHMMXX3oHJOyp2/Z0IYVe7rpcWaoEHwasPMA4qTueU09Gv4KgmPSI4j8f2VbGu/HHg6YH4OLnb4zdnvJKtBy5BpBYkQcAVVJvItHc7dE0yqt7GzAfHZ6PYBmrTiIBm0B8aCua1CnFvtSUdQlxB5ast0GoTDJg82IokUBpwx/uLVkMouylCU5vtV3+mzCJAvKhcxGC6aJ/iPvyvzUVRvB5PHBnLeqYuYfIKV04nHzuABeJcDph43jF9mB9rfW7DT0VC6MJ2u84gDmF2TbbJwgRA== 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: Hi, On 3/1/23 05:37, Matthew Wilcox (Oracle) wrote: > Add set_ptes() and update_mmu_cache_range(). It would probably be > more efficient to implement __update_tlb() by flushing the entire > folio instead of calling it __update_tlb() N times, but I'll leave > that for someone who understands the architecture better. Thanks for the patch! Unfortunately it doesn't seem possible architecture-wise to batch-flush pages right now on loongarch, but AFAIK the vendor *could* be listening so a future model could have the feature supported... who knows! > > Signed-off-by: Matthew Wilcox (Oracle) > Cc: Huacai Chen > Cc: WANG Xuerui > Cc: loongarch@lists.linux.dev > --- > arch/loongarch/include/asm/cacheflush.h | 2 ++ > arch/loongarch/include/asm/pgtable.h | 30 +++++++++++++++++++------ > 2 files changed, 25 insertions(+), 7 deletions(-) > > diff --git a/arch/loongarch/include/asm/cacheflush.h b/arch/loongarch/include/asm/cacheflush.h > index 0681788eb474..7907eb42bfbd 100644 > --- a/arch/loongarch/include/asm/cacheflush.h > +++ b/arch/loongarch/include/asm/cacheflush.h > @@ -47,8 +47,10 @@ void local_flush_icache_range(unsigned long start, unsigned long end); > #define flush_cache_vmap(start, end) do { } while (0) > #define flush_cache_vunmap(start, end) do { } while (0) > #define flush_icache_page(vma, page) do { } while (0) > +#define flush_icache_pages(vma, page) do { } while (0) > #define flush_icache_user_page(vma, page, addr, len) do { } while (0) > #define flush_dcache_page(page) do { } while (0) > +#define flush_dcache_folio(folio) do { } while (0) This will break the build because the surrounding code is unnecessarily redefining the stubs that the asm-generic include at the end of the file will properly take care of. With the build fixed (patch attached below), I can successfully boot-test and stress mm for a while on a Loongson 3A5000. I haven't done the benchmarks though. > #define flush_dcache_mmap_lock(mapping) do { } while (0) > #define flush_dcache_mmap_unlock(mapping) do { } while (0) > > Cleanup patch: -- >8 -- From 0de3f49e6ba23c1b45e7b5da355f87398c4a7feb Mon Sep 17 00:00:00 2001 From: WANG Xuerui Date: Wed, 1 Mar 2023 09:32:18 +0800 Subject: [PATCH] LoongArch: Remove stub definitions in cacheflush.h Per the current best practice in mm, it's unnecessary to define no-op stubs explicitly in arch code, because the asm-generic inclusion at the end of the file will properly take care of these. And the definition of ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE to 0 is going to confuse the asm-generic code, so remove the stubs for clarity and avoiding misuse. Signed-off-by: WANG Xuerui --- arch/loongarch/include/asm/cacheflush.h | 15 --------------- 1 file changed, 15 deletions(-) diff --git a/arch/loongarch/include/asm/cacheflush.h b/arch/loongarch/include/asm/cacheflush.h index 326ac6f1b27c..cb8c046b4f17 100644 --- a/arch/loongarch/include/asm/cacheflush.h +++ b/arch/loongarch/include/asm/cacheflush.h @@ -37,21 +37,6 @@ void local_flush_icache_range(unsigned long start, unsigned long end); #define flush_icache_range local_flush_icache_range #define flush_icache_user_range local_flush_icache_range -#define ARCH_IMPLEMENTS_FLUSH_DCACHE_PAGE 0 - -#define flush_cache_all() do { } while (0) -#define flush_cache_mm(mm) do { } while (0) -#define flush_cache_dup_mm(mm) do { } while (0) -#define flush_cache_range(vma, start, end) do { } while (0) -#define flush_cache_page(vma, vmaddr, pfn) do { } while (0) -#define flush_cache_vmap(start, end) do { } while (0) -#define flush_cache_vunmap(start, end) do { } while (0) -#define flush_icache_user_page(vma, page, addr, len) do { } while (0) -#define flush_dcache_page(page) do { } while (0) -#define flush_dcache_folio(folio) do { } while (0) -#define flush_dcache_mmap_lock(mapping) do { } while (0) -#define flush_dcache_mmap_unlock(mapping) do { } while (0) - #define cache_op(op, addr) \ __asm__ __volatile__( \ " cacop %0, %1 \n" \ -- WANG "xen0n" Xuerui Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/