[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1601200957580.3575@nanos>
Date: Wed, 20 Jan 2016 10:03:32 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Frederic Weisbecker <fweisbec@...il.com>
cc: Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>,
Byungchul Park <byungchul.park@....com>,
Chris Metcalf <cmetcalf@...hip.com>,
Luiz Capitulino <lcapitulino@...hat.com>,
Christoph Lameter <cl@...ux.com>,
"Paul E . McKenney" <paulmck@...ux.vnet.ibm.com>,
Mike Galbraith <efault@....de>, Rik van Riel <riel@...hat.com>
Subject: Re: [RFC PATCH 4/4] sched: Upload nohz full CPU load on task
enqueue/dequeue
On Wed, 13 Jan 2016, Frederic Weisbecker wrote:
> A solution to fix this is to update the CPU load everytime we enqueue
> or dequeue a task in the fair runqueue and more than a jiffy occured
> since the last update.
That's not a solution. That's just crap.
I tell you since years, that you need to fix that remote accounting stuff,
but no, you insist on adding more trainwrecks left and right.
> The problem with doing this remotely is that we can miss past cpu loads if
> there was several enqueue/dequeue operations happening while tickless.
That's complete bullshit.
1) How is remote accounting that happens every tick different from local
accounting which happens every tick?
2) How do you have enqueue/dequeue operations when you are running in full
nohz, i.e. one task is consuming 100% cpu time in user space?
I'm really tired of that tinkering. The proper solution is to make NOHZ_FULL
depend on BROKEN.
Thanks,
tglx
Powered by blists - more mailing lists