On Tue, Nov 17, 2020 at 07:06:33PM +0000, Christopher Lameter wrote: > On Tue, 17 Nov 2020, Matthew Wilcox wrote: > > > On Tue, Nov 17, 2020 at 01:28:06PM -0300, Marcelo Tosatti wrote: > > > For isolated applications that busy loop (packet processing with DPDK, > > > for example), workqueue functions either stall (if the -rt app priority > > > is higher than kworker thread priority) or interrupt the -rt app > > > (if the -rt app priority is lower than kworker thread priority. > > > > This seems a bit obscure to expect an application to do. Can we make > > this happen automatically when we bind an rt task to a group of CPUs? > > Well the way we used it was just to let things be and run in the busy > loop. There could be another flush of the vmstat data and then the vmstat > worker will disable itself. So two more workqueue executions before the > processor completely dies down. But then we also need a period like > that to trigger the NOHZ logic to switch off the timer. Right? The application should not start its time sensitive loop until the workqueues have finished execution. > So what we would need would be something like a sysctl that puts the > system into a quiet state by completing all workqueue items. Idle all > subsystems that need it and put the cpu into NOHZ mode. Are you suggesting that instead of a specific file to control vmstat workqueue only, a more generic sysctl could be used? About NOHZ mode: the CPU should enter NOHZ automatically as soon as there is a single thread running, so unclear why that would be needed. Thanks.
