On Tue, Nov 17, 2020 at 05:23:17PM -0300, Marcelo Tosatti wrote: > 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. Hi Christoph, Can you expand on the suggestion? TIA
