Re: [PATCHv5 19/28] mm: store mapcount for compound page separately

[Vlastimil Babka]

On 05/19/2015 05:55 AM, Kirill A. Shutemov wrote:
> > > +	if (compound_mapcount(page))
> > > +	       ret += compound_mapcount(page) - 1;
> >
> > This looks like it could uselessly duplicate-inline the code for
> > compound_mapcount(). It has atomics and smp_rmb() so I'm not sure if the
> > compiler can just "squash it".
>
> Good point. I'll rework this.

Hm BTW I think same duplication of compound_head() happens in 
lock_page(), where it's done by trylock_page() and then __lock_page(), 
which is also in different compilation unit to make things worse.

I can imagine it's solvable by introducing variants of __lock_page* that 
expect to be already given a head page... if it's worth the trouble.

> > On the other hand, a simple atomic read that was page_mapcount() has turned
> > into multiple atomic reads and flag checks. What about the stability of the
> > whole result? Are all callers ok? (maybe a later page deals with it).
>
> Urghh.. I'll look into this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/