Re: [RFC PATCH 4/6] mm, compaction: skip buddy pages by their order in the migrate scanner

[Vlastimil Babka]

On 06/12/2014 02:21 AM, David Rientjes wrote:
> On Wed, 11 Jun 2014, Vlastimil Babka wrote:
>
> > > I hate to belabor this point, but I think gcc does treat it differently.
> > > If you look at the assembly comparing your patch to if you do
> > >
> > > 	unsigned long freepage_order = ACCESS_ONCE(page_private(page));
> > >
> > > instead, then if you enable annotation you'll see that gcc treats the
> > > store as page_x->D.y.private in your patch vs. MEM[(volatile long unsigned
> > > int *)page_x + 48B] with the above.
> >
> > Hm sure you compiled a version that used page_order_unsafe() and not
> > page_order()? Because I do see:
> >
> > MEM[(volatile long unsigned int *)valid_page_114 + 48B];
> >
> > That's gcc 4.8.1, but our gcc guy said he tried 4.5+ and all was like this.
> > And that it would be a gcc bug if not.
> > He also did a test where page_order was called twice in one function and
> > page_order_unsafe twice in another function. page_order() was reduced to a
> > single access in the assembly, page_order_unsafe were two accesses.
>
> Ok, and I won't continue to push the point.

I'd rather know I'm correct and not just persistent enough :) If you 
confirm that your compiler behaves differently, then maybe making 
page_order_unsafe a #define instead of inline function would prevent 
this issue?

> I think the lockless
> suitable_migration_target() call that looks at page_order() is fine in the
> free scanner since we use it as a racy check, but it might benefit from
> either a comment describing the behavior or a sanity check for
> page_order(page) <= MAX_ORDER as you've done before.

OK, I'll add that.
--
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/