Received: by 2002:a05:6358:3188:b0:123:57c1:9b43 with SMTP id q8csp5304306rwd; Tue, 23 May 2023 22:58:49 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ7xugDa0n302iCNIwT0yeD4nO7tX4/k7sozsTdp9pXSWT77i77whcFZi2so4y0y2+ppw2yY X-Received: by 2002:a05:6a20:3d8b:b0:103:7b36:f21 with SMTP id s11-20020a056a203d8b00b001037b360f21mr18774231pzi.21.1684907928712; Tue, 23 May 2023 22:58:48 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1684907928; cv=none; d=google.com; s=arc-20160816; b=WLsIJPoGqQ5fQCvBvmSaxI5C1E/5+iJ8kXtUV29DVnaiyEk+o3xZXNssX17eaWT/jw 9xxqRNQSe0ToOmsB9l36cdECjwkRO3ULy2kkNBAxq0AjjBC2crDNVbwEUEBvGuUyB2ZN sPavuzk50kGe5mH6Odgkp5mKuh79mPSqelL/pcpO62UoZSPmddapgf7US4FVcOfKgIim yUr72fMLFhVWVHTlBLF5dix94OCSn1tX4td3VGttV5DOtBlP79I1l4wXVQ9eYznoQ17o Hxqk1BsFM7YVaLRKwtraGwn2XaX4KSXOfWwFE8Vq0y25Ehq126rcEhrz8i3i3UmNgGEi 2i6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=aS3Nhb3VAWEGlLu+XBwgpmCXcyJvTR79ms1GmCOYiuc=; b=mDQc//O5g+L3w875m3oGr2cmNPkrU+9ZNfsOa/UhjSEy2dcy3VyqIfpZiRAAAcfa/A c0TSWniQ28K1zQI//o6VrnxQ416jy7UdsUVFTdCegWnMzLQVjS6/QcUSo6BZFec1FjZ5 UTO7EDValWU5AadM/oEf37vTsP/7VESN2+p6V5oe0Oh9kykEGOaOWAImsx7HVrZpTual QaFNZWN/OfLVRX/GSbFUOFpnE4V2Rl9vnlEtGK9SjdtR+gvtoQJCvi7JpTj888O+GGZJ qu3GJW3iid8lgw/Wxx5YDeA5mCM3+7KzdcpgNj8mHE3MFLcX10fcZ9IihVm9sECq0V9z S71w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=yHK9rzEq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id e2-20020a637442000000b00536e63cbd99si5774156pgn.20.2023.05.23.22.58.34; Tue, 23 May 2023 22:58:48 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20221208 header.b=yHK9rzEq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239396AbjEXF2x (ORCPT + 99 others); Wed, 24 May 2023 01:28:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57200 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S239363AbjEXF2m (ORCPT ); Wed, 24 May 2023 01:28:42 -0400 Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 856D613E for ; Tue, 23 May 2023 22:28:41 -0700 (PDT) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5621a279cbbso10713097b3.1 for ; Tue, 23 May 2023 22:28:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684906120; x=1687498120; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=aS3Nhb3VAWEGlLu+XBwgpmCXcyJvTR79ms1GmCOYiuc=; b=yHK9rzEq2VzEMfw2DClczT1cZ0xt1Sc1yfEDGlQ/piJkXnt8SYE6F8347x9r4Bnc4X 5iu3V89eWxuFne6sR9CxkQ6TxK6EN/6k7xBX1U24kVBLCxj0/5whUbyYRpkJBxC9+85Q qqvV1OC49D6WylWj5VRJukBH6nVXLiiZnWrGw7MJOfNnudiIuo1Wu8eRwGaol4pdIkqT mJXhFmDRVi/PyVkDerk/ALdFKhRrvkAuKqS0sctgyaFABXSacfned5FhxHdfNtu1TwO+ i4pfgPYu6LKg+XSwBDJi7TyvTqRGiO2lfSZsYPaVWA+nZ4XwxxojQ5ChtP3PdIDKRzqK 7OCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684906120; x=1687498120; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=aS3Nhb3VAWEGlLu+XBwgpmCXcyJvTR79ms1GmCOYiuc=; b=HFHHJpA3fDXKmnOYmWzpJ1G6maK/3vEyiz1K5DMy9s5AkHlzy9Lztf+JNIIiv0r8Y4 3j8bMl40H3HeFsDilLfYwtpkeZyi+eGg5G+C98k/ftXMrxC2QKYO4QuEDKMFJ7X/THjb JHGqGCLAh20hIGLc4wtYvyPGFPXFmhxY0ssUSXu/vLE3o8Ko9Z02sh1YRyV48JetzweU Jn5KwZHUnV89q/pBzINOr2sPeZ5X72SSDeuKtopZ93XdR25nNsdtm44Rq4ViIAjd4iVq 852pBuIYe4vY2QQXLRE7hn9ctH60vDRApJ5Sykr8yDxZ7hVYF/lJyA28/vJOjQDuf710 kZEQ== X-Gm-Message-State: AC+VfDzM7oORahZ48Y5zFG8IttTMG/GuEpKkKK6awsyEKbQtAG+756FY mw27tdqkNFhvc4QXQ9Oa245WLSBCfWGQZjq+4p6m2TxGqAym2zbX3IAqpw== X-Received: by 2002:a05:690c:810:b0:565:62e7:223a with SMTP id bx16-20020a05690c081000b0056562e7223amr925533ywb.3.1684906120498; Tue, 23 May 2023 22:28:40 -0700 (PDT) MIME-Version: 1.0 References: <20230523165942.2630-1-jszhang@kernel.org> <20230524050259.104358-1-guoren@kernel.org> In-Reply-To: <20230524050259.104358-1-guoren@kernel.org> From: Suren Baghdasaryan Date: Tue, 23 May 2023 22:28:29 -0700 Message-ID: Subject: Re: [PATCH] riscv: mm: try VMA lock-based page fault handling first To: guoren@kernel.org Cc: jszhang@kernel.org, aou@eecs.berkeley.edu, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, palmer@dabbelt.com, paul.walmsley@sifive.com, chenhuacai@kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 23, 2023 at 10:03=E2=80=AFPM wrote: > > > Attempt VMA lock-based page fault handling first, and fall back to the > > existing mmap_lock-based handling if that fails. > > > > A simple running the ebizzy benchmark on Lichee Pi 4A shows that > > PER_VMA_LOCK can improve the ebizzy benchmark by about 32.68%. In > Good improvement, I think VMA lock is worth to support in riscv. > > Please give more details about ebizzy, Is it > https://github.com/linux-test-project/ltp/blob/master/utils/benchmark/ebi= zzy-0.3/ebizzy.c > ? > > > theory, the more CPUs, the bigger improvement, but I don't have any > > HW platform which has more than 4 CPUs. > > > > This is the riscv variant of "x86/mm: try VMA lock-based page fault > > handling first". > > > > How about add Link tag here: > Link: https://lwn.net/Articles/906852/ > > > Signed-off-by: Jisheng Zhang > > --- > > Any performance numbers are welcome! Especially the numbers on HW > > platforms with 8 or more CPUs. > > > > arch/riscv/Kconfig | 1 + > > arch/riscv/mm/fault.c | 33 +++++++++++++++++++++++++++++++++ > > 2 files changed, 34 insertions(+) > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index 62e84fee2cfd..b958f67f9a12 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -42,6 +42,7 @@ config RISCV > > select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU > > select ARCH_SUPPORTS_HUGETLBFS if MMU > > select ARCH_SUPPORTS_PAGE_TABLE_CHECK if MMU > > + select ARCH_SUPPORTS_PER_VMA_LOCK if MMU > > select ARCH_USE_MEMTEST > > select ARCH_USE_QUEUED_RWLOCKS > > select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU > > diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c > > index 8685f85a7474..eccdddf26f4b 100644 > > --- a/arch/riscv/mm/fault.c > > +++ b/arch/riscv/mm/fault.c > > @@ -286,6 +286,36 @@ void handle_page_fault(struct pt_regs *regs) > > flags |=3D FAULT_FLAG_WRITE; > > else if (cause =3D=3D EXC_INST_PAGE_FAULT) > > flags |=3D FAULT_FLAG_INSTRUCTION; > > +#ifdef CONFIG_PER_VMA_LOCK > > + if (!(flags & FAULT_FLAG_USER)) > > + goto lock_mmap; > > + > > + vma =3D lock_vma_under_rcu(mm, addr); > > + if (!vma) > > + goto lock_mmap; > > + > > + if (unlikely(access_error(cause, vma))) { > > + vma_end_read(vma); > > + goto lock_mmap; > > + } > > + > > + fault =3D handle_mm_fault(vma, addr, flags | FAULT_FLAG_VMA_LOCK,= regs); > > + vma_end_read(vma); > > + > > + if (!(fault & VM_FAULT_RETRY)) { > > + count_vm_vma_lock_event(VMA_LOCK_SUCCESS); > > + goto done; > > + } > > + count_vm_vma_lock_event(VMA_LOCK_RETRY); > > + > > + if (fault_signal_pending(fault, regs)) { > > + if (!user_mode(regs)) > > + no_context(regs, addr); > > + return; > > + } > > +lock_mmap: > > +#endif /* CONFIG_PER_VMA_LOCK */ > > + > > retry: > > mmap_read_lock(mm); > > vma =3D find_vma(mm, addr); > > @@ -355,6 +385,9 @@ void handle_page_fault(struct pt_regs *regs) > > > > mmap_read_unlock(mm); > > > > +#ifdef CONFIG_PER_VMA_LOCK > > +done: > > +#endif > It's very close to cd7f176aea5f ("arm64/mm: try VMA lock-based page fault > handling first"), and I didn't find any problem. So: > > Reviewed-by: Guo Ren Looks correct to me. Reviewed-by: Suren Baghdasaryan > > F.Y.I Huacai Chen, maybe he also would be interesting this new feature. > > > > if (unlikely(fault & VM_FAULT_ERROR)) { > > tsk->thread.bad_cause =3D cause; > > mm_fault_error(regs, addr, fault); > > -- > > 2.40.1