Re: [PATCH RFC] mm: Add function for testing if the current lruvec lock is valid

在 2020/8/3 上午2:20, Alexander Duyck 写道: > Feel free to fold it into your patches if you want. > > I think Hugh was the one that had submitted a patch that addressed it, > and it looks like you folded that into your v17 set. It was probably > what he had identified which was the additional LRU ch

Re: [PATCH RFC] mm: Add function for testing if the current lruvec lock is valid

Feel free to fold it into your patches if you want. I think Hugh was the one that had submitted a patch that addressed it, and it looks like you folded that into your v17 set. It was probably what he had identified which was the additional LRU checks needing to be removed from the code. Thanks.

Re: [PATCH RFC] mm: Add function for testing if the current lruvec lock is valid

It looks much better than mine. and could replace 'mm/lru: introduce the relock_page_lruvec function' with your author signed. :) BTW, it's the rcu_read_lock cause the will-it-scale/page_fault3 regression which you mentained in another letter? Thanks Alex 在 2020/8/1 上午5:14, alexander.h.du...@i

[PATCH RFC] mm: Add function for testing if the current lruvec lock is valid

From: Alexander Duyck When testing for relock we can avoid the need for RCU locking if we simply compare the page pgdat and memcg pointers versus those that the lruvec is holding. By doing this we can avoid the extra pointer walks and accesses of the memory cgroup. In addition we can avoid the c