clflush uses a virtual address but cache line is physical indexed in
x86. In my understanding, clflush will do some pagetable walk, so doing
cache flush first should reduce some pagetable walk.
Signed-off-by: Shaohua Li <[email protected]>
diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index f5f5154..d8b24df 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -168,10 +168,8 @@ static void cpa_flush_range(unsigned long start, int numpages, int cache)
BUG_ON(irqs_disabled());
WARN_ON(PAGE_ALIGN(start) != start);
- on_each_cpu(__cpa_flush_range, NULL, 1);
-
if (!cache)
- return;
+ goto tlb_flush;
/*
* We only need to flush on one CPU,
@@ -188,6 +186,9 @@ static void cpa_flush_range(unsigned long start, int numpages, int cache)
if (pte && (pte_val(*pte) & _PAGE_PRESENT))
clflush_cache_range((void *) addr, PAGE_SIZE);
}
+
+tlb_flush:
+ on_each_cpu(__cpa_flush_range, NULL, 1);
}
/*
Shaohua Li wrote:
> clflush uses a virtual address but cache line is physical indexed in
> x86. In my understanding, clflush will do some pagetable walk, so doing
> cache flush first should reduce some pagetable walk.
>
> Signed-off-by: Shaohua Li <[email protected]>
I would say NAK on this.
Doing the CLFLUSH first does cut down on page table walking, but opens a
hole in the sequencing: first set PAT to an uncachable mode, then flush.
If an unlucky prefetch comes in during this window, then you will have a
dirty cache again.
So no, this is not a good idea.
-hpa
>-----Original Message-----
>From: H. Peter Anvin [mailto:[email protected]]
>Sent: Tuesday, August 19, 2008 1:10 PM
>To: Li, Shaohua
>Cc: lkml; Andrew Morton; Ingo Molnar; Pallipadi, Venkatesh
>Subject: Re: [patch]pageattr: cache flush before tlb flush
>
>Shaohua Li wrote:
>> clflush uses a virtual address but cache line is physical indexed in
>> x86. In my understanding, clflush will do some pagetable walk, so doing
>> cache flush first should reduce some pagetable walk.
>>
>> Signed-off-by: Shaohua Li <[email protected]>
>
>I would say NAK on this.
>
>Doing the CLFLUSH first does cut down on page table walking, but opens a
>hole in the sequencing: first set PAT to an uncachable mode, then flush.
>
>If an unlucky prefetch comes in during this window, then you will have a
>dirty cache again.
>
>So no, this is not a good idea.
Ok, looks possible in theory.
Thanks,
Shaohua
Shaohua Li <[email protected]> writes:
> clflush uses a virtual address but cache line is physical indexed in
> x86. In my understanding, clflush will do some pagetable walk, so doing
> cache flush first should reduce some pagetable walk.
The SDM describes the exact sequence how this should be done.
Linux unfortunately skips one step currently, but it's not a good
idea to diverge even more.
-Andi