On 1/11/22 3:47 AM, Idan Horowitz wrote:
+/*
+ * If the length is larger than the jump cache size, then it will take
+ * longer to clear each entry individually than it will to clear it all.
+ */
+if (d.len >= (TARGET_PAGE_SIZE * TB_JMP_CACHE_SIZE)) {
+cpu_tb_jmp_cache
Idan Horowitz wrote:
>
> cbnz x9, 0x5168abc8
>
I forgot to include the addresses of the instructions, making this
jump undecipherable, here's the snippet again but with addresses this
time:
0x5168abb0 movkx0, #0x0
0x5168abb4 movkx0, #0x0, lsl #16
0x5168abb8 movkx0, #0xff80, lsl #
Alex Bennée wrote:
>
>
> For multi-patch series please include a cover letter which is the parent
> of all the patches. This is the default for git-send-email.
>
Sorry, I will do so from now on.
>
> The code itself looks fine but what sort of improvements are we talking
> about here? What measur
Idan Horowitz writes:
> When the length of the range is large enough, clearing the whole cache is
> faster than iterating over the (possibly extremely large) set of pages
> contained in the range.
>
> This mimics the pre-existing similar optimization done on the flush of the
> tlb itself.
>
> S
When the length of the range is large enough, clearing the whole cache is
faster than iterating over the (possibly extremely large) set of pages
contained in the range.
This mimics the pre-existing similar optimization done on the flush of the
tlb itself.
Signed-off-by: Idan Horowitz
---
accel/
