linux-kernel - Re: [PATCH v19 18/20] mm/lru: replace pgdat lru

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 21 Oct 2020 15:23:34 +0800
From:   Alex Shi <alex.shi@...ux.alibaba.com>
To:     akpm@...ux-foundation.org, mgorman@...hsingularity.net,
        tj@...nel.org, hughd@...gle.com, khlebnikov@...dex-team.ru,
        daniel.m.jordan@...cle.com, willy@...radead.org,
        hannes@...xchg.org, lkp@...el.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
        shakeelb@...gle.com, iamjoonsoo.kim@....com,
        richard.weiyang@...il.com, kirill@...temov.name,
        alexander.duyck@...il.com, rong.a.chen@...el.com, mhocko@...e.com,
        vdavydov.dev@...il.com, shy828301@...il.com, aaron.lwe@...il.com
Cc:     Michal Hocko <mhocko@...nel.org>,
        Yang Shi <yang.shi@...ux.alibaba.com>,
        Rong Chen <rong.a.chen@...el.com>,
        "lkp@...ux.intel.com" <lkp@...ux.intel.com>
Subject: Re: [PATCH v19 18/20] mm/lru: replace pgdat lru_lock with lruvec lock


在 2020/9/24 上午11:28, Alex Shi 写道:
> --- a/include/linux/mmzone.h
> +++ b/include/linux/mmzone.h
> @@ -273,6 +273,8 @@ enum lruvec_flags {
>  };
>  
>  struct lruvec {
> +	/* per lruvec lru_lock for memcg */
> +	spinlock_t			lru_lock;
>  	struct list_head		lists[NR_LRU_LISTS];
>  	/*
>  	 * These track the cost of reclaiming one LRU - file or anon -

Hi All,

Intel Rong Chen, LKP, report a big regression on this patch, about 12 ~ 32% performance drop on fio.read_iops and case-lru-file-mmap-read case on wide Intel machine with attached kernel config. Hugh Dickins pointed it's a false sharing issue on the lru_lock. And that could be fixed by move the lru_lock out of busy lists[] cacheline, like the following patch:

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index a75e6d0effcb..58b21bffef95 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -272,9 +272,9 @@ enum lruvec_flags {
 };

 struct lruvec {
+       struct list_head                lists[NR_LRU_LISTS];
        /* per lruvec lru_lock for memcg */
        spinlock_t                      lru_lock;
-       struct list_head                lists[NR_LRU_LISTS];
        /*
         * These track the cost of reclaiming one LRU - file or anon -
         * over the other. As the observed cost of reclaiming one LRU

Although the problem fixed， But I still no idea of the reasons and the gut problem. Any comments for this?


Thanks
Alex

View attachment "config-5.9.0-rc5-00174-g872102b4f76574" of type "text/plain" (170149 bytes)