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