On Wed 14-04-21 13:49:56, Johannes Weiner wrote: > On Wed, Apr 14, 2021 at 06:00:42PM +0800, Muchun Song wrote: > > On Wed, Apr 14, 2021 at 5:44 PM Michal Hocko <mhocko@xxxxxxxx> wrote: > > > > > > On Tue 13-04-21 14:51:50, Muchun Song wrote: > > > > We already have a helper lruvec_memcg() to get the memcg from lruvec, we > > > > do not need to do it ourselves in the lruvec_holds_page_lru_lock(). So use > > > > lruvec_memcg() instead. And if mem_cgroup_disabled() returns false, the > > > > page_memcg(page) (the LRU pages) cannot be NULL. So remove the odd logic > > > > of "memcg = page_memcg(page) ? : root_mem_cgroup". And use lruvec_pgdat > > > > to simplify the code. We can have a single definition for this function > > > > that works for !CONFIG_MEMCG, CONFIG_MEMCG + mem_cgroup_disabled() and > > > > CONFIG_MEMCG. > > > > > > Neat. While you are at it wouldn't it make sesne to rename the function > > > as well. I do not want to bikeshed but this is really a misnomer. it > > > doesn't check anything about locking. page_belongs_lruvec? > > > > Right. lruvec_holds_page_lru_lock is used to check whether > > the page belongs to the lruvec. page_belongs_lruvec > > obviously more clearer. I can rename it to > > page_belongs_lruvec the next version. > > This sounds strange to me, I think 'belongs' needs a 'to' to be > correct, so page_belongs_to_lruvec(). Still kind of a mouthful. > > page_matches_lruvec()? > > page_from_lruvec()? Any of those is much better than what we have here. -- Michal Hocko SUSE Labs
