Messages in this thread | | | Date | Wed, 30 Mar 2022 20:23:27 +0200 | From | Peter Zijlstra <> | Subject | Re: [External] Re: [PATCH] sched/fair: fix broken bandwidth control with nohz_full |
| |
On Mon, Mar 28, 2022 at 12:44:54PM -0400, Steven Rostedt wrote: > On Mon, 28 Mar 2022 17:56:07 +0200 > Peter Zijlstra <peterz@infradead.org> wrote: > > > > echo $$ > test/cgroup.procs > > > taskset -c 1 bash -c "while true; do let i++; done" --> will be throttled > > > > Ofcourse.. I'm arguing that bandiwdth control and NOHZ_FULL are somewhat > > mutually exclusive, use-case wise. So I really don't get why you'd want > > them both. > > Is it? > > One use case I can see for having both is for having a deadline task that > needs to get something done in a tight deadline. NOHZ_FULL means "do not > interrupt this task when it is the top priority task on the CPU and is > running in user space".
This is absolute batshit.. It means no such thing. We'll happily wake another task to this CPU and re-enable the tick any instant.
Worse; the use-case at hand pertains to cfs bandwidth control, which pretty much guarantees there *will* be an interrupt.
> Why is it mutually exclusive to have a deadline task that does not want to > be interrupted by timer interrupts?
This has absolutely nothing to do with deadline tasks, nada, noppes.
> Just because the biggest pushers of NOHZ_FULL is for those that are running > RT tasks completely in user space and event want to fault if it ever goes > into the kernel, doesn't mean that's the only use case.
Because there's costs associated with the whole thing. system entry/exit get far more expensive. It just doesn't make much sense to use NOHZ_FULL if you're not absoultely limiting system entry.
> Chengming brought up VMs. That's a case to want to control the bandwidth, > but also not interrupt them with timer interrupts when they are running as > the top priority task on a CPU.
It's CFS, there is nothing top priority about that.
| |