linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Matthew Wilcox <willy@infradead.org>
To: Alex Shi <alex.shi@linux.alibaba.com>
Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	mgorman@techsingularity.net, tj@kernel.org, hughd@google.com,
	khlebnikov@yandex-team.ru, daniel.m.jordan@oracle.com,
	yang.shi@linux.alibaba.com, Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vladimir Davydov <vdavydov.dev@gmail.com>,
	Roman Gushchin <guro@fb.com>, Shakeel Butt <shakeelb@google.com>,
	Chris Down <chris@chrisdown.name>,
	Thomas Gleixner <tglx@linutronix.de>,
	Vlastimil Babka <vbabka@suse.cz>,
	Andrey Ryabinin <aryabinin@virtuozzo.com>,
	swkhack <swkhack@gmail.com>,
	"Potyra, Stefan" <Stefan.Potyra@elektrobit.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
	Peng Fan <peng.fan@nxp.com>, Nikolay Borisov <nborisov@suse.com>,
	Ira Weiny <ira.weiny@intel.com>,
	Kirill Tkhai <ktkhai@virtuozzo.com>,
	Yafang Shao <laoar.shao@gmail.com>
Subject: Re: [PATCH v2 4/8] mm/lru: only change the lru_lock iff page's lruvec is different
Date: Wed, 13 Nov 2019 05:45:02 -0800	[thread overview]
Message-ID: <20191113134502.GD7934@bombadil.infradead.org> (raw)
In-Reply-To: <297ad71c-081c-f7e1-d640-8720a0eeeeba@linux.alibaba.com>

On Wed, Nov 13, 2019 at 10:26:24AM +0800, Alex Shi wrote:
> 在 2019/11/12 下午10:36, Matthew Wilcox 写道:
> > On Tue, Nov 12, 2019 at 10:06:24PM +0800, Alex Shi wrote:
> >> +/* Don't lock again iff page's lruvec locked */
> >> +static inline struct lruvec *relock_page_lruvec_irq(struct page *page,
> >> +					struct lruvec *locked_lruvec)
> >> +{
> >> +	struct pglist_data *pgdat = page_pgdat(page);
> >> +	struct lruvec *lruvec;
> >> +
> >> +	rcu_read_lock();
> >> +	lruvec = mem_cgroup_page_lruvec(page, pgdat);
> >> +
> >> +	if (locked_lruvec == lruvec) {
> >> +		rcu_read_unlock();
> >> +		return lruvec;
> >> +	}
> >> +	rcu_read_unlock();
> > 
> > Why not simply:
> > 
> > 	rcu_read_lock();
> > 	lruvec = mem_cgroup_page_lruvec(page, pgdat);
> > 	rcu_read_unlock();
> > 
> > 	if (locked_lruvec == lruvec)
> 
> The rcu_read_unlock here is for guarding the locked_lruvec/lruvec comparsion.
> Otherwise memcg/lruvec maybe changed, like, from memcg migration etc. I guess.

How does holding the RCU lock guard the comparison?  You're comparing two
pointers for equality.  Nothing any other CPU can do at this point will
change the results of that comparison.

> > Also, why are you bothering to re-enable interrupts here?  Surely if
> > you're holding lock A with interrupts disabled , you can just drop lock A,
> > acquire lock B and leave the interrupts alone.  That way you only need
> > one of this variety of function, and not the separate irq/irqsave variants.
> > 
> 
> Thanks for the suggestion! Yes, if only do re-lock, it's better to leave the irq unchanging. but, when the locked_lruvec is NULL, it become a first time lock which irq or irqsave are different. Thus, in combined function we need a nother parameter to indicate if it do irqsaving. So comparing to a extra/indistinct parameter, I guess 2 inline functions would be a bit more simple/cleary? 

Ah, right, I missed the "if it's not held" case.


  reply	other threads:[~2019-11-13 13:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-12 14:06 [PATCH v2 0/8] per lruvec lru_lock for memcg Alex Shi
2019-11-12 14:06 ` [PATCH v2 1/8] mm/lru: add per lruvec lock " Alex Shi
2019-11-12 14:06 ` [PATCH v2 2/8] mm/lruvec: add irqsave flags into lruvec struct Alex Shi
2019-11-12 14:06 ` [PATCH v2 3/8] mm/lru: replace pgdat lru_lock with lruvec lock Alex Shi
2019-11-12 14:06 ` [PATCH v2 4/8] mm/lru: only change the lru_lock iff page's lruvec is different Alex Shi
2019-11-12 14:36   ` Matthew Wilcox
2019-11-13  2:26     ` Alex Shi
2019-11-13 13:45       ` Matthew Wilcox [this message]
2019-11-14  6:01         ` Alex Shi
2019-11-12 14:06 ` [PATCH v2 5/8] mm/pgdat: remove pgdat lru_lock Alex Shi
2019-11-12 14:06 ` [PATCH v2 6/8] mm/lru: remove rcu_read_lock to fix performance regression Alex Shi
2019-11-12 14:38   ` Matthew Wilcox
2019-11-13  2:40     ` Alex Shi
2019-11-13 11:40       ` Mel Gorman
2019-11-14  6:02         ` Alex Shi
2019-11-12 14:06 ` [PATCH v2 7/8] mm/lru: likely enhancement Alex Shi
2019-11-12 14:06 ` [PATCH v2 8/8] mm/lru: revise the comments of lru_lock Alex Shi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20191113134502.GD7934@bombadil.infradead.org \
    --to=willy@infradead.org \
    --cc=Stefan.Potyra@elektrobit.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.shi@linux.alibaba.com \
    --cc=aryabinin@virtuozzo.com \
    --cc=cgroups@vger.kernel.org \
    --cc=chris@chrisdown.name \
    --cc=daniel.m.jordan@oracle.com \
    --cc=guro@fb.com \
    --cc=hannes@cmpxchg.org \
    --cc=hughd@google.com \
    --cc=ira.weiny@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=khlebnikov@yandex-team.ru \
    --cc=ktkhai@virtuozzo.com \
    --cc=laoar.shao@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mchehab+samsung@kernel.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@kernel.org \
    --cc=nborisov@suse.com \
    --cc=peng.fan@nxp.com \
    --cc=shakeelb@google.com \
    --cc=swkhack@gmail.com \
    --cc=tglx@linutronix.de \
    --cc=tj@kernel.org \
    --cc=vbabka@suse.cz \
    --cc=vdavydov.dev@gmail.com \
    --cc=yang.shi@linux.alibaba.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox