Received: by 2002:a05:6902:102b:0:0:0:0 with SMTP id x11csp992189ybt; Fri, 19 Jun 2020 20:51:40 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzMnP4/C90NSqSlhcb9A+pTMuBP8gX4xulEbeUmtmDGzHeCD4Xv7oKTIiA2zRg2wqfVDWKS X-Received: by 2002:a17:906:b28e:: with SMTP id q14mr6338972ejz.484.1592625100508; Fri, 19 Jun 2020 20:51:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1592625100; cv=none; d=google.com; s=arc-20160816; b=nanUsQcAmrZI7BAxbAs/LDqvF8fowZMKi3VWL3mSMCWrZ/AvRwua11xZioGYCKzhK4 PwcJWgPPXTQJlcoHf8Hsj2Qf9urLBKqvf516GY8bY8Dnm4FBHaPTwrH/zgrckAZAOnXl DS/9APowEaArTc1TMbC61chAJxWgKtLypcNF3QB5bLw4CPgyfCWG+E/flyrkAwpE4l7+ LETwSkfDKHE1GO0lH41Jp9XcaCZ8psf5MRPQGa65kZUFeoJ8kb3GDkHZGfZrtoiZj56S Yp6H5P7LyjI3HQb4mNlKn4ulTrJhz2snL4djDNaPJqtIEgIL6FmD66fGgukfSxbxWeo3 AlVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=djMzqxEX2KOhdS0mA0I6TixiZlYRFWjkTEipCw3bAqk=; b=L4752MJi3nFZABEc19jn9VMyVT1FuOOUay/lRcf9ioxYa9PQUWISZCHHali1ZciARO zNGKEsd/rdkAzeyAFym619r9cuXrRqa3Nc5PT8fT6ojEFwQ3ngiJQ1FC9stWCl16t6zh jKILFn/zbjVar6W0bn4YsmkqHoViYA5IxBmy7hm2ipGB1V/4drNTTTbiOwk3WXixDRww 33fQdsjWjbOoUJZyiwIaXJRYu9CDXHaBsJJudFZ16rGfSDrCgNlHPCM3TtP4i45aospQ h7Xvh/nKhUtl2g1nreM/5MLQKDaOCoDcxMkpuaKJWtXwDsDaQAnjGWf1IvkgUyEWceoE GzZg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FD8m5Tgw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id z3si5173713eja.429.2020.06.19.20.51.18; Fri, 19 Jun 2020 20:51:40 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=FD8m5Tgw; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394435AbgFSQOg (ORCPT + 99 others); Fri, 19 Jun 2020 12:14:36 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:43237 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2394409AbgFSQN6 (ORCPT ); Fri, 19 Jun 2020 12:13:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1592583236; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=djMzqxEX2KOhdS0mA0I6TixiZlYRFWjkTEipCw3bAqk=; b=FD8m5Tgw2ml9LIDH4YDfv1p/uZrt15qPXwJ1WBvhi6KL0HFAHSWPQPwjniHnBZuF2uLsKL vXpNBB8Jm0j4i2xJcORvxgpVY2BxNlc34tpFRjP1QgLB3Ye/74YTuMhKSggcgkdWz8ZwjA qtrEifV/GV0i00aDD9nQSWtUUw+UOpg= Received: from mail-qt1-f198.google.com (mail-qt1-f198.google.com [209.85.160.198]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-299-myY3j4gRMHqX6oVuc-UZAg-1; Fri, 19 Jun 2020 12:13:55 -0400 X-MC-Unique: myY3j4gRMHqX6oVuc-UZAg-1 Received: by mail-qt1-f198.google.com with SMTP id x6so7495851qts.3 for ; Fri, 19 Jun 2020 09:13:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=djMzqxEX2KOhdS0mA0I6TixiZlYRFWjkTEipCw3bAqk=; b=blaAucGqCbf3OBCUIr8dfFiHQ3JuQj9GJlt8Txr0EPlRu1Z5DFXPBeFMH4n5C+cr1b WLhhcAEui1sX5uUOS0I5yeP0H8c68vu+8zKj2Vmv0YqrrCVGMMWye9LXi9RJ/Z+tJRWU 5LQsnyCigpQlnyYcucBNq0EE8GZqOmXTOEvf1cqiBWXVT30QTGGVbmtwXpAOSnbidC2K pTk4q9lmy6nRgwwjIA2I7sS/52QVClpylCaKZOjXhpWaL9Bt/XEquiRTSSulBwl3ZaXI 4eKdWuUfvgq4z1bPyhiiqxGnyH3qg9o6dR3v4BrvYTGIV8SVB3cakS1AZambKZmvoOr0 da+g== X-Gm-Message-State: AOAM532bq/61S6ld2RyMUO2mDUafbmYkd2JpV5N9Gl5QEjP78IuxjilS JgQVmmMSnxTzZPOxaHHrdZWXYzsETy2VrwGNk6z1dVO5snWdznejGMSTwRfEE5NpRPLz9gI6QCU E/28gyjvrLwrQ220Rukr5Vjfp X-Received: by 2002:a05:620a:538:: with SMTP id h24mr3790627qkh.13.1592583234297; Fri, 19 Jun 2020 09:13:54 -0700 (PDT) X-Received: by 2002:a05:620a:538:: with SMTP id h24mr3790569qkh.13.1592583233626; Fri, 19 Jun 2020 09:13:53 -0700 (PDT) Received: from xz-x1.redhat.com ([2607:9880:19c0:32::2]) by smtp.gmail.com with ESMTPSA id z46sm6066253qtb.57.2020.06.19.09.13.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 19 Jun 2020 09:13:52 -0700 (PDT) From: Peter Xu To: linux-kernel@vger.kernel.org, linux-mm@kvack.org Cc: Peter Xu , Gerald Schaefer , Andrew Morton , Andrea Arcangeli , Will Deacon , Michael Ellerman , Linus Torvalds , Guan Xuetao Subject: [PATCH 22/26] mm/unicore32: Use general page fault accounting Date: Fri, 19 Jun 2020 12:13:51 -0400 Message-Id: <20200619161351.9859-1-peterx@redhat.com> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200619160538.8641-1-peterx@redhat.com> References: <20200619160538.8641-1-peterx@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Use the general page fault accounting by passing regs into handle_mm_fault(). It naturally solve the issue of multiple page fault accounting when page fault retry happened. Add the missing PERF_COUNT_SW_PAGE_FAULTS perf events too. Note, the other two perf events (PERF_COUNT_SW_PAGE_FAULTS_[MAJ|MIN]) were done in handle_mm_fault(). CC: Guan Xuetao Signed-off-by: Peter Xu --- arch/unicore32/mm/fault.c | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/unicore32/mm/fault.c b/arch/unicore32/mm/fault.c index 847ff24fcc2a..b272a389d977 100644 --- a/arch/unicore32/mm/fault.c +++ b/arch/unicore32/mm/fault.c @@ -16,6 +16,7 @@ #include #include #include +#include #include #include @@ -160,7 +161,8 @@ static inline bool access_error(unsigned int fsr, struct vm_area_struct *vma) } static vm_fault_t __do_pf(struct mm_struct *mm, unsigned long addr, - unsigned int fsr, unsigned int flags, struct task_struct *tsk) + unsigned int fsr, unsigned int flags, + struct task_struct *tsk, struct pt_regs *regs) { struct vm_area_struct *vma; vm_fault_t fault; @@ -186,7 +188,7 @@ static vm_fault_t __do_pf(struct mm_struct *mm, unsigned long addr, * If for any reason at all we couldn't handle the fault, make * sure we exit gracefully rather than endlessly redo the fault. */ - fault = handle_mm_fault(vma, addr & PAGE_MASK, flags, NULL); + fault = handle_mm_fault(vma, addr & PAGE_MASK, flags, regs); return fault; check_stack: @@ -219,6 +221,8 @@ static int do_pf(unsigned long addr, unsigned int fsr, struct pt_regs *regs) if (!(fsr ^ 0x12)) flags |= FAULT_FLAG_WRITE; + perf_sw_event(PERF_COUNT_SW_PAGE_FAULTS, 1, regs, addr); + /* * As per x86, we may deadlock here. However, since the kernel only * validly references user space from well defined areas of the code, @@ -244,7 +248,7 @@ static int do_pf(unsigned long addr, unsigned int fsr, struct pt_regs *regs) #endif } - fault = __do_pf(mm, addr, fsr, flags, tsk); + fault = __do_pf(mm, addr, fsr, flags, tsk, regs); /* If we need to retry but a fatal signal is pending, handle the * signal first. We do not need to release the mmap_sem because @@ -254,10 +258,6 @@ static int do_pf(unsigned long addr, unsigned int fsr, struct pt_regs *regs) return 0; if (!(fault & VM_FAULT_ERROR) && (flags & FAULT_FLAG_ALLOW_RETRY)) { - if (fault & VM_FAULT_MAJOR) - tsk->maj_flt++; - else - tsk->min_flt++; if (fault & VM_FAULT_RETRY) { flags |= FAULT_FLAG_TRIED; goto retry; -- 2.26.2