Re: [PATCH 2/6] ksm: add cond_resched() to the rmap_walks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Oct 26, 2015 at 05:32:02PM -0700, Davidlohr Bueso wrote:
> On Sun, 25 Oct 2015, Hugh Dickins wrote:
> 
> >On Thu, 15 Oct 2015, Andrea Arcangeli wrote:
> >
> >> While at it add it to the file and anon walks too.
> >>
> >> Signed-off-by: Andrea Arcangeli <aarcange@xxxxxxxxxx>
> >
> >Subject really should be "mm: add cond_resched() to the rmap walks",
> >then body "Add cond_resched() to the ksm and anon and file rmap walks."
> >
> >Acked-by: Hugh Dickins <hughd@xxxxxxxxxx>
> >but I think we need a blessing from Davidlohr too, if not more.
> 
> Perhaps I'm lost in the context, but by the changelog alone I cannot
> see the reasoning for the patch. Are latencies really that high? Maybe,
> at least the changelog needs some love.

Yes they can be that high. The rmap walk must reach every possible
mapping of the page, so if a page is heavily shared (no matter if it's
KSM, anon, pagecache) there will be tons of entries to walk
through. All optimizations with prio_tree, anon_vma chains, interval
tree, helps to find the right virtual mapping faster, but if there are
lots of virtual mappings, all mapping must still be walked through.

The biggest cost is for the IPIs and the IPIs can be optimized in a
variety of ways, but at least for KSM if each virtual mapping ends up
in a different mm and each mm runs in a different CPU and if there are
tons of CPUs, it's actually impossible to reduce the number of IPIs
during KSM page migration.

Regardless of the IPIs, it's generally safer to keep these
cond_resched() in all cases, as even if we massively reduce the number
of IPIs, the number of entries to walk IPI-less may still be large and
no entry can be possibly skipped in the page migration case. Plus we
leverage having made those locks sleepable.

Dropping 1/6 triggers a reject in a later patch, so I'll have to
resubmit. So while at it, I'll add more commentary to the commit.

Thanks,
Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]