Re: [PATCH 2/2] ksm: Optimize rmap_walk_ksm by passing a suitable address range
From: xu.xin16
Date: Wed Jan 14 2026 - 20:42:17 EST
> >>> Solution
> >>> ========
> >>> In fact, we can significantly improve performance by passing a more precise
> >>> range based on the given addr. Since the original pages merged by KSM
> >>> correspond to anonymous VMAs, the page offset can be calculated as
> >>> pgoff = address >> PAGE_SHIFT. Therefore, we can optimize the call by
> >>> defining:
> >>>
> >>> pgoff_start = rmap_item->address >> PAGE_SHIFT;
> >>> pgoff_end = pgoff_start + folio_nr_pages(folio) - 1;
> >>>
> >>> Performance
> >>> ===========
> >>> In our real embedded Linux environment, the measured metrcis were as follows:
> >>>
> >>> 1) Time_ms: Max time for holding anon_vma lock in a single rmap_walk_ksm.
> >>> 2) Nr_iteration_total: The max times of iterations in a loop of anon_vma_interval_tree_foreach
> >>> 3) Skip_addr_out_of_range: The max times of skipping due to the first check (vma->vm_start
> >>> and vma->vm_end) in a loop of anon_vma_interval_tree_foreach.
> >>> 4) Skip_mm_mismatch: The max times of skipping due to the second check (rmap_item->mm == vma->vm_mm)
> >>> in a loop of anon_vma_interval_tree_foreach.
> >>>
> >>> The result is as follows:
> >>>
> >>> Time_ms Nr_iteration_total Skip_addr_out_of_range Skip_mm_mismatch
> >>> Before patched: 228.65 22169 22168 0
> >>> After pacthed: 0.396 3 0 2
> >>
> >> Nice improvement.
> >>
> >> Can you make your reproducer available?
> >
> > I'll do my best to try it. The original test data was derived from real business scenarios,
> > but it's quite complex. I'll try to simplify this high-latency scenario into a more
> > understandable demo as a reproduction program.
>
> Ah, I thought it was some benchmark ran on an embedded environment.
>
> How did you end up measuring these numbers?
>
That was done by inserting livepatch.ko to modify the rmap_walk_ksm().