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

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

 



On Mon,  2 Mar 2020 19:00:10 +0800 Alex Shi <alex.shi@xxxxxxxxxxxxxxxxx> 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.



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

  Powered by Linux