On Wed, Dec 07, 2016 at 09:19:58PM +0000, Mel Gorman wrote: > At small packet sizes on localhost, I see relatively low page allocator > activity except during the socket setup and other unrelated activity > (khugepaged, irqbalance, some btrfs stuff) which is curious as it's > less clear why the performance was improved in that case. I considered > the possibility that it was cache hotness of pages but that's not a > good fit. If it was true then the first test would be slow and the rest > relatively fast and I'm not seeing that. The other side-effect is that > all the high-order pages that are allocated at the start are physically > close together but that shouldn't have that big an impact. So for now, > the gain is unexplained even though it happens consistently. > Further investigation led me to conclude that the netperf automation on my side had some methodology errors that could account for an artifically low score in some cases. The netperf automation is years old and would have been developed against a much older and smaller machine which may be why I missed it until I went back looking at exactly what the automation was doing. Minimally in a server/client test on remote maching there was potentially higher packet loss than is acceptable. This would account why some machines "benefitted" while others did not -- there would be boot to boot variations that some machines happened to be "lucky". I believe I've corrected the errors, discarded all the old data and scheduled a rest to see what falls out. -- Mel Gorman 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>