[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200825113910.GM17456@casper.infradead.org>
Date: Tue, 25 Aug 2020 12:39:10 +0100
From: Matthew Wilcox <willy@...radead.org>
To: Alex Shi <alex.shi@...ux.alibaba.com>
Cc: Daniel Jordan <daniel.m.jordan@...cle.com>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
mgorman@...hsingularity.net, tj@...nel.org,
khlebnikov@...dex-team.ru, 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
Subject: Re: [PATCH v18 00/32] per memcg lru_lock
On Tue, Aug 25, 2020 at 11:26:58AM +0800, Alex Shi wrote:
> I tried reusing page->prviate to store lruvec pointer, that could remove some
> regression on this, since private is generally unused on a lru page. But the patch
> is too buggy now.
page->private is for the use of the filesystem. You can grep for
attach_page_private() to see how most filesystems use it.
Some still use set_page_private() for various reasons.
Powered by blists - more mailing lists