On Thu 22-01-15 10:11:31, Christoph Lameter wrote: > On Wed, 21 Jan 2015, Michal Hocko wrote: > > > I think we can solve this as well. We can stick vmstat_shepherd into a > > kernel thread with a loop with the configured timeout and then create a > > mask of CPUs which need the update and run vmstat_update from > > IPI context (smp_call_function_many). > > Please do not run the vmstat_updates concurrently. They update shared > cachelines and therefore can cause bouncing cachelines if run concurrently > on multiple cpus. Would you preffer to call smp_call_function_single on each CPU which needs an update? That would make vmstat_shepherd slower but that is not a big deal, is it? Anyway I am wondering whether the cache line bouncing between vmstat_update instances is a big deal in the real life. Updating shared counters whould bounce with many CPUs but this is an operation which is not done often. Also all the CPUs would have update the same counters all the time and I am not sure this happens that often. Do you have a load where this would be measurable? -- 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>