On Wed 07-01-15 10:15:39, Vlastimil Babka wrote: > On 01/06/2015 04:09 PM, Michal Hocko wrote: > > On Mon 05-01-15 18:17:43, Vlastimil Babka wrote: > >> The function next_zones_zonelist() returns zoneref pointer, as well as zone > >> pointer via extra parameter. Since the latter can be trivially obtained by > >> dereferencing the former, the overhead of the extra parameter is unjustified. > >> > >> This patch thus removes the zone parameter from next_zones_zonelist(). Both > >> callers happen to be in the same header file, so it's simple to add the > >> zoneref dereference inline. We save some bytes of code size. > > > > Dunno. It makes first_zones_zonelist and next_zones_zonelist look > > different which might be a bit confusing. It's not a big deal but > > I am not sure it is worth it. > > Yeah I thought that nobody uses them directly anyway thanks to > for_each_zone_zonelist* so it's not a big deal. OK, I have checked why we need the whole struct zoneref when it only caches zone_idx. dd1a239f6f2d (mm: have zonelist contains structs with both a zone pointer and zone_idx) claims this will reduce cache contention by reducing pointer chasing because we do not have to dereference pgdat so often in hot paths. Fair enough but I do not see any numbers in the changelog nor in the original discussion (https://lkml.org/lkml/2007/11/20/547 resp. https://lkml.org/lkml/2007/9/28/170). Maybe Mel remembers what was the benchmark which has shown the difference so that we can check whether this is still relevant and caching the index is still worth it. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>