[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220328124454.08ab6126@gandalf.local.home>
Date: Mon, 28 Mar 2022 12:44:54 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Chengming Zhou <zhouchengming@...edance.com>, mingo@...hat.com,
juri.lelli@...hat.com, vincent.guittot@...aro.org,
dietmar.eggemann@....com, bsegall@...gle.com, mgorman@...e.de,
bristot@...hat.com, linux-kernel@...r.kernel.org,
duanxiongchun@...edance.com, songmuchun@...edance.com,
Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [External] Re: [PATCH] sched/fair: fix broken bandwidth control
with nohz_full
On Mon, 28 Mar 2022 17:56:07 +0200
Peter Zijlstra <peterz@...radead.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".
Why is it mutually exclusive to have a deadline task that does not want to
be interrupted by timer interrupts?
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.
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.
-- Steve
Powered by blists - more mailing lists