On Fri, Nov 14, 2014 at 10:33:01AM +0000, Mel Gorman wrote: > > > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h > > > index 4593567..3d090af 100644 > > > --- a/include/linux/mmzone.h > > > +++ b/include/linux/mmzone.h > > > @@ -431,6 +431,15 @@ struct zone { > > > */ > > > int nr_migrate_reserve_block; > > > > > > +#ifdef CONFIG_MEMORY_ISOLATION > > > + /* > > > + * Number of isolated pageblock. It is used to solve incorrect > > > + * freepage counting problem due to racy retrieving migratetype > > > + * of pageblock. Protected by zone->lock. > > > + */ > > > + unsigned long nr_isolate_pageblock; > > > +#endif > > > + > > > > First sorry for this deferred reply, I see these patches have been merged > > into the mainline. > > However, I still have a tiny question: > > Why use ZONE_PADDING(_pad1_) seperate it and zone->lock? > > How about move it to the same cacheline with zone->lock, because it is > > accessed under zone->lock? > > > > zone->lock is currently sharing lines with the data that is frequently > updated under zone lock and some of the dirty data cache line bouncing has > completed when the lock is acquired. nr_isolate_pageblock is a read-mostly > field and in some cases will never be used. It's fine where it is beside > other read-mostly fields. >
My bad... I don't remember why I decide that place. :/ It seems better to move nr_isolate_pageblock to the same cacheline with zone->lock, but, as Mel said, it is rarely used field so improvement would be marginal. Thanks. -- 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/