Messages in this thread | | | Date | Thu, 1 Oct 2020 14:59:50 -0400 | From | Johannes Weiner <> | Subject | Re: [PATCH v4 1/4] mm: memcontrol: use helpers to access page's memcg data |
| |
On Thu, Oct 01, 2020 at 11:27:39AM -0700, Roman Gushchin wrote: > On Thu, Oct 01, 2020 at 09:46:38AM -0400, Johannes Weiner wrote: > > On Wed, Sep 30, 2020 at 05:27:07PM -0700, Roman Gushchin wrote: > > > +/* > > > + * set_page_memcg - associate a page with a memory cgroup > > > + * @page: a pointer to the page struct > > > + * @memcg: a pointer to the memory cgroup > > > + * > > > + * Associates a page with a memory cgroup. > > > + */ > > > +static inline void set_page_memcg(struct page *page, struct mem_cgroup *memcg) > > > +{ > > > + VM_BUG_ON_PAGE(PageSlab(page), page); > > > + > > > + /* > > > + * Please, refer to page_memcg()'s description for the page and memcg > > > + * binding stability requirements. > > > + */ > > > + page->memcg_data = (unsigned long)memcg; > > > +} > > > > Please delete and inline this as per previous feedback, thanks. > > Why it's better? > It's ok for set_page_memcg(), but obviously worse for set_page_objcgs(): > it was nice to have all bit magic in one place, in few helper functions. > And now it spills into several places. What's the win?
set_page_objcgs() is a worthwhile abstraction because it includes the synchronization primitives that make it safe to use wrt page_objcgs(). They encapsulate the cmpxchg and the READ_ONCE().
set_page_memcg() doesn't do any synchronization and relies fully on the contextual locking. The name implies that it includes things to make it safe wrt page_memcg(), which isn't true at all. It's a long and misleading name for '='.
Btw, I really don't mind having this discussion, but please don't send revisions that silently ignore feedback you don't agree with.
Thanks
| |