[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160624134515.GC30154@twins.programming.kicks-ass.net>
Date: Fri, 24 Jun 2016 15:45:15 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Vincent Guittot <vincent.guittot@...aro.org>
Cc: Jirka Hladky <jhladky@...hat.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
Ingo Molnar <mingo@...hat.com>,
Kamil Kolakowski <kkolakow@...hat.com>,
Morten Rasmussen <morten.rasmussen@....com>,
Yuyang Du <yuyang.du@...el.com>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Mike Galbraith <umgwanakikbuti@...il.com>,
Benjamin Segall <bsegall@...gle.com>,
Paul Turner <pjt@...gle.com>,
Matt Fleming <matt@...eblueprint.co.uk>
Subject: Re: Kernel 4.7rc3 - Performance drop 30-40% for SPECjbb2005 and
SPECjvm2008 benchmarks against 4.6 kernel
On Fri, Jun 24, 2016 at 03:23:37PM +0200, Vincent Guittot wrote:
> > It seemed like a simple and cheap way to increase accuracy, nothing more
> > behind it until the commit you referred to.
>
> Thanks for the clarification.
> I thought that the difference should always be smaller than 1/64th of
> the cfs_rq->avg.load_avg thanks to update_tg_load_avg
Right, another reason I just remembered is that it ensures:
tg_weight >= cfs_rq_weight
Because if this is the only task in the entire group and cfs_rq
increased (but did not exceed the 1/64th threshold) you get the group
weight being smaller than the entity weight, which would be weird.
Powered by blists - more mailing lists