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? > > 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. Why does it need to be something userspace does? It would seem reasonable that the kernel could figure out for itself that it's about to start this CPU operating in isolated mode and flush all the work first?
