2019-04-29 21:29:10

by Atish Patra

Subject: [PATCH v3 3/3] RISC-V: Update tlb flush counters

The TLB flush counters under vmstat seems to be very helpful while
debugging TLB flush performance in RISC-V.

Update the counters in every TLB flush methods respectively.

Signed-off-by: Atish Patra <[email protected]>
---
arch/riscv/include/asm/tlbflush.h | 5 +++++
arch/riscv/mm/tlbflush.c | 12 ++++++++++++
2 files changed, 17 insertions(+)

diff --git a/arch/riscv/include/asm/tlbflush.h b/arch/riscv/include/asm/tlbflush.h
index 29a780ca232a..19779a083f52 100644
--- a/arch/riscv/include/asm/tlbflush.h
+++ b/arch/riscv/include/asm/tlbflush.h
@@ -9,6 +9,7 @@
#define _ASM_RISCV_TLBFLUSH_H

#include <linux/mm_types.h>
+#include <linux/vmstat.h>

/*
* Flush entire local TLB. 'sfence.vma' implicitly fences with the instruction
@@ -16,11 +17,13 @@
*/
static inline void local_flush_tlb_all(void)
{
+ count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
__asm__ __volatile__ ("sfence.vma" : : : "memory");
}

static inline void local_flush_tlb_mm(struct mm_struct *mm)
{
+ count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
/* Flush ASID 0 so that global mappings are not affected */
__asm__ __volatile__ ("sfence.vma x0, %0" : : "r" (0) : "memory");
}
@@ -28,6 +31,7 @@ static inline void local_flush_tlb_mm(struct mm_struct *mm)
static inline void local_flush_tlb_page(struct vm_area_struct *vma,
unsigned long addr)
{
+ count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ONE);
__asm__ __volatile__ ("sfence.vma %0, %1"
: : "r" (addr), "r" (0)
: "memory");
@@ -35,6 +39,7 @@ static inline void local_flush_tlb_page(struct vm_area_struct *vma,

static inline void local_flush_tlb_kernel_page(unsigned long addr)
{
+ count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ONE);
__asm__ __volatile__ ("sfence.vma %0" : : "r" (addr) : "memory");
}

diff --git a/arch/riscv/mm/tlbflush.c b/arch/riscv/mm/tlbflush.c
index ceee76f14a0a..8072d7da32bb 100644
--- a/arch/riscv/mm/tlbflush.c
+++ b/arch/riscv/mm/tlbflush.c
@@ -4,6 +4,8 @@
*/

#include <linux/mm.h>
+#include <linux/vmstat.h>
+#include <linux/cpumask.h>
#include <asm/sbi.h>

#define SFENCE_VMA_FLUSH_ALL ((unsigned long) -1)
@@ -110,6 +112,7 @@ static void ipi_remote_sfence_vma(void *info)
unsigned long size = data->size;
unsigned long i;

+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
if (size == SFENCE_VMA_FLUSH_ALL) {
local_flush_tlb_all();
}
@@ -129,6 +132,8 @@ static void ipi_remote_sfence_vma_asid(void *info)
unsigned long size = data->size;
unsigned long i;

+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH_RECEIVED);
+ /* Flush entire MM context */
if (size == SFENCE_VMA_FLUSH_ALL) {
__asm__ __volatile__ ("sfence.vma x0, %0"
: : "r" (asid)
@@ -158,6 +163,13 @@ static void remote_sfence_vma(unsigned long start, unsigned long size)
static void remote_sfence_vma_asid(cpumask_t *mask, unsigned long start,
unsigned long size, unsigned long asid)
{
+ int cpuid = smp_processor_id();
+
+ if (cpumask_equal(mask, cpumask_of(cpuid)))
+ count_vm_tlb_event(NR_TLB_LOCAL_FLUSH_ALL);
+ else
+ count_vm_tlb_event(NR_TLB_REMOTE_FLUSH);
+
if (tlbi_ipi) {
struct tlbi info = {
.start = start,
--
2.21.0

2019-06-28 05:48:11

by Paul Walmsley

Subject: Re: [PATCH v3 3/3] RISC-V: Update tlb flush counters

On Mon, 29 Apr 2019, Atish Patra wrote:

> The TLB flush counters under vmstat seems to be very helpful while
> debugging TLB flush performance in RISC-V.
>
> Update the counters in every TLB flush methods respectively.
>
> Signed-off-by: Atish Patra <[email protected]>

This one doesn't apply any longer. Care to update and repost?


- Paul

2019-06-28 16:37:44

by Atish Patra

Subject: Re: [PATCH v3 3/3] RISC-V: Update tlb flush counters

On 6/27/19 10:47 PM, Paul Walmsley wrote:
> On Mon, 29 Apr 2019, Atish Patra wrote:
>
>> The TLB flush counters under vmstat seems to be very helpful while
>> debugging TLB flush performance in RISC-V.
>>
>> Update the counters in every TLB flush methods respectively.
>>
>> Signed-off-by: Atish Patra <[email protected]>
>
> This one doesn't apply any longer. Care to update and repost?
>
>
> - Paul
>

Yeah. The baseline patch (Gary's patch) was not accepted. I will rebase
it on top of master and resend.

--
Regards,
Atish