[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200930210649.GC469663@cmpxchg.org>
Date: Wed, 30 Sep 2020 17:06:49 -0400
From: Johannes Weiner <hannes@...xchg.org>
To: Roman Gushchin <guro@...com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Shakeel Butt <shakeelb@...gle.com>,
Michal Hocko <mhocko@...nel.org>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, kernel-team@...com
Subject: Re: [PATCH v3 4/4] mm: convert page kmemcg type to a page memcg flag
On Tue, Sep 29, 2020 at 04:59:20PM -0700, Roman Gushchin wrote:
> @@ -449,6 +455,36 @@ static inline void clear_page_memcg(struct page *page)
> page->memcg_data = 0;
> }
>
> +/*
> + * PageMemcgKmem - check if the page has MemcgKmem flag set
> + * @page: a pointer to the page struct
> + *
> + * Checks if the page has MemcgKmem flag set. The caller must ensure that
> + * the page has an associated memory cgroup. It's not safe to call this function
> + * against some types of pages, e.g. slab pages.
> + */
> +static inline bool PageMemcgKmem(struct page *page)
> +{
> + VM_BUG_ON_PAGE(test_bit(MEMCG_DATA_OBJCGS, &page->memcg_data), page);
> + return test_bit(MEMCG_DATA_KMEM, &page->memcg_data);
Most other places need the bit mask and have to do ad-hoc shifting,
which is verbose and causes awkward line wrapping in various places.
There are no atomic accesses here, so there is no need to use the
atomic bitop interface here. I feel like I've mentioned this before.
Just make the MEMCG_DATA_ items bitfields directly, and do
return page->memcg_data & MEMCG_DATA_KMEM
here.
Thanks
Powered by blists - more mailing lists