On Mon, 15 May 2017, Marcelo Tosatti wrote: > > NOHZ already does that. I wanted to know what your problem is that you > > see. The latency issue has already been solved as far as I can tell . > > Please tell me why the existing solutions are not sufficient for you. > > We don't want vmstat_worker to execute on a given CPU, even if the local > CPU updates vm-statistics. Instead of responding you repeat describing what you want. > Because: > > vmstat_worker increases latency of the application > (i can measure it if you want on a given CPU, > how many ns's the following takes: That still is no use case. Just a measurement of vmstat_worker. Pointless. If you move the latency from the vmstat worker into the code thats updating the counters then you will require increased use of atomics which will increase contention which in turn will significantly increase the overall latency. > Why the existing solutions are not sufficient: > > 1) task-isolation patchset seems too heavy for our usecase (we do > want IPIs, signals, etc). Ok then minor delays from remote random events are tolerable? Then you can also have a vmstat update. > So this seems a little heavy for our usecase. Sorry all of this does not make sense to me. Maybe get some numbers of of an app with intensive OS access running with atomics vs vmstat worker? NOHZ currently disables the vmstat worker when no updates occur. This is applicable to DPDK and will provide a quiet vmstat worker free environment if no statistics activity is occurring. -- 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>
