On 01/24/2018 10:19 AM, Mel Gorman wrote: >> IOW, I don't think this has the same downsides normally associated with >> prefetch() since the data is always used. > That doesn't side-step the calculations are done twice in the > free_pcppages_bulk path and there is no guarantee that one prefetch > in the list of pages being freed will not evict a previous prefetch > due to collisions. Fair enough. The description here could probably use some touchups to explicitly spell out the downsides. I do agree with you that there is no guarantee that this will be resident in the cache before use. In fact, it might be entertaining to see if we can show the extra conflicts in the L1 given from this change given a large enough PCP batch size. But, this isn't just about the L1. If the results of the prefetch() stay in *ANY* cache, then the memory bandwidth impact of this change is still zero. You'll have a lot harder time arguing that we're likely to see L2/L3 evictions in this path for our typical PCP batch sizes. Do you want to see some analysis for less-frequent PCP frees? We could pretty easily instrument the latency doing normal-ish things to see if we can measure a benefit from this rather than a tight-loop micro. -- 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>
