All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Byungchul Park <byungchul.park@lge.com>,
	Chris Metcalf <cmetcalf@ezchip.com>,
	Luiz Capitulino <lcapitulino@redhat.com>,
	Christoph Lameter <cl@linux.com>,
	"Paul E . McKenney" <paulmck@linux.vnet.ibm.com>,
	Mike Galbraith <efault@gmx.de>, Rik van Riel <riel@redhat.com>
Subject: Re: [RFC PATCH 4/4] sched: Upload nohz full CPU load on task enqueue/dequeue
Date: Wed, 20 Jan 2016 10:03:32 +0100 (CET)	[thread overview]
Message-ID: <alpine.DEB.2.11.1601200957580.3575@nanos> (raw)
In-Reply-To: <1452700891-21807-5-git-send-email-fweisbec@gmail.com>

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

  parent reply	other threads:[~2016-01-20  9:04 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-13 16:01 [RFC PATCH 0/4] sched: Improve cpu load accounting with nohz Frederic Weisbecker
2016-01-13 16:01 ` [PATCH 1/4] sched: Don't account tickless CPU load on tick Frederic Weisbecker
2016-01-19 13:08   ` Peter Zijlstra
2016-01-19 16:22     ` Frederic Weisbecker
2016-01-19 18:56       ` Peter Zijlstra
2016-01-19 22:33         ` Frederic Weisbecker
2016-01-20  5:43           ` Byungchul Park
2016-01-20 10:26             ` Byungchul Park
2016-01-28 16:01               ` Frederic Weisbecker
2016-01-29  9:50                 ` Peter Zijlstra
2016-02-01 10:05                   ` Byungchul Park
2016-02-01 10:09                     ` [PATCH] sched: calculate sched_clock_cpu without tick handling during nohz Byungchul Park
2016-02-01 10:34                     ` [PATCH 1/4] sched: Don't account tickless CPU load on tick Peter Zijlstra
2016-02-01 23:51                       ` Byungchul Park
2016-02-02  0:50                       ` Byungchul Park
2016-02-01  6:33               ` Byungchul Park
2016-01-20  8:42     ` Thomas Gleixner
2016-01-20 17:36       ` Frederic Weisbecker
2016-01-22  8:40       ` Byungchul Park
2016-01-13 16:01 ` [PATCH 2/4] sched: Consolidate nohz CPU load update code Frederic Weisbecker
2016-01-14  2:30   ` Byungchul Park
2016-01-19 13:13     ` Peter Zijlstra
2016-01-20  0:51       ` Byungchul Park
2016-01-14  5:18   ` Byungchul Park
2016-01-19 13:13     ` Peter Zijlstra
2016-01-19 16:49     ` Frederic Weisbecker
2016-01-20  1:41       ` Byungchul Park
2016-02-29 11:14   ` [tip:sched/core] sched/fair: " tip-bot for Frederic Weisbecker
2016-01-13 16:01 ` [RFC PATCH 3/4] sched: Move cpu load stats functions above fair queue callbacks Frederic Weisbecker
2016-01-13 16:01 ` [RFC PATCH 4/4] sched: Upload nohz full CPU load on task enqueue/dequeue Frederic Weisbecker
2016-01-19 13:17   ` Peter Zijlstra
2016-01-19 17:03     ` Frederic Weisbecker
2016-01-20  9:09       ` Peter Zijlstra
2016-01-20 14:54         ` Frederic Weisbecker
2016-01-20 15:11           ` Thomas Gleixner
2016-01-20 15:19             ` Christoph Lameter
2016-01-20 16:52               ` Frederic Weisbecker
2016-01-20 16:45             ` Frederic Weisbecker
2016-01-20 16:56           ` Peter Zijlstra
2016-01-20 17:21             ` Frederic Weisbecker
2016-01-20 18:25               ` Peter Zijlstra
2016-01-21 13:25                 ` Frederic Weisbecker
2016-01-20  9:03   ` Thomas Gleixner [this message]
2016-01-20 14:31     ` Frederic Weisbecker
2016-01-20 14:43       ` Thomas Gleixner
2016-01-20 16:40         ` Frederic Weisbecker
2016-01-20 16:42           ` Christoph Lameter
2016-01-20 16:47             ` Frederic Weisbecker
2016-01-14 21:19 ` [RFC PATCH 0/4] sched: Improve cpu load accounting with nohz Dietmar Eggemann
2016-01-14 21:27   ` Peter Zijlstra
2016-01-14 22:23     ` Dietmar Eggemann
2016-01-15  7:07       ` Byungchul Park
2016-01-15 16:56         ` Dietmar Eggemann
2016-01-18  0:23           ` Byungchul Park
2016-01-19 13:04           ` Peter Zijlstra
2016-01-20  0:48             ` Byungchul Park
2016-01-20 13:04               ` Dietmar Eggemann
2016-02-29 11:14         ` [tip:sched/core] sched/fair: Avoid using decay_load_missed() with a negative value tip-bot for Byungchul Park

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.11.1601200957580.3575@nanos \
    --to=tglx@linutronix.de \
    --cc=byungchul.park@lge.com \
    --cc=cl@linux.com \
    --cc=cmetcalf@ezchip.com \
    --cc=efault@gmx.de \
    --cc=fweisbec@gmail.com \
    --cc=lcapitulino@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=riel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.