Re: [PATCH v9 00/21] per lruvec lru_lock for memcg

Andrew Morton
2020-03-02T22:12:02Z

On Mon, 2 Mar 2020 19:00:10 +0800 Alex Shi <alex.shi-KPsoFbNs7GizrGE5bRqYAgC/G2K4zDHf@public.gmane.org> wrote:

> Hi all,
>
> This patchset mainly includes 3 parts:
> 1, some code cleanup and minimum optimization as a preparation.
> 2, use TestCleanPageLRU as page isolation's precondition
> 3, replace per node lru_lock with per memcg per node lru_lock
>
> The keypoint of this patchset is moving lru_lock into lruvec, give a
> lru_lock for each of lruvec, thus bring a lru_lock for each of memcg
> per node. So on a large node machine, each of memcg don't suffer from
> per node pgdat->lru_lock waiting. They could go fast with their self
> lru_lock now.
>
> Since lruvec belongs to each memcg, the critical point is to keep
> page's memcg stable, so we take PageLRU as its isolation's precondition.
> Thanks for Johannes Weiner help and suggestion!
>
> Following Daniel Jordan's suggestion, I have run 208 'dd' with on 104
> containers on a 2s * 26cores * HT box with a modefied case:
> https://git.kernel.org/pub/scm/linux/kernel/git/wfg/vm-scalability.git/tree/case-lru-file-readtwice
>
> With this patchset, the readtwice performance increased about 80%
> in concurrent containers.
>
> Thanks Hugh Dickins and Konstantin Khlebnikov, they both brought this
> idea 8 years ago, and others who give comments as well: Daniel Jordan,
> Mel Gorman, Shakeel Butt, Matthew Wilcox etc.
>
> Thanks for Testing support from Intel 0day and Rong Chen, Fengguang Wu,
> and Yun Wang.

I'm not seeing a lot of evidence of review and test activity yet. But
I think I'll grab patches 01-06 as they look like fairly
straightforward improvements.