From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756231AbcANVTP (ORCPT ); Thu, 14 Jan 2016 16:19:15 -0500 Received: from eu-smtp-delivery-143.mimecast.com ([146.101.78.143]:47669 "EHLO eu-smtp-delivery-143.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752702AbcANVTM convert rfc822-to-8bit (ORCPT ); Thu, 14 Jan 2016 16:19:12 -0500 Subject: Re: [RFC PATCH 0/4] sched: Improve cpu load accounting with nohz To: Frederic Weisbecker , Peter Zijlstra References: <1452700891-21807-1-git-send-email-fweisbec@gmail.com> CC: LKML , Byungchul Park , Chris Metcalf , Thomas Gleixner , Luiz Capitulino , Christoph Lameter , "Paul E . McKenney" , Mike Galbraith , Rik van Riel From: Dietmar Eggemann Message-ID: <569810C4.7090900@arm.com> Date: Thu, 14 Jan 2016 21:19:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <1452700891-21807-1-git-send-email-fweisbec@gmail.com> X-Originating-IP: [217.140.96.140] X-ClientProxiedBy: AM3PR02CA0008.eurprd02.prod.outlook.com (25.163.180.18) To DB4PR08MB0141.eurprd08.prod.outlook.com (25.161.17.25) X-Microsoft-Exchange-Diagnostics: 1;DB4PR08MB0141;2:w+PnRJS/v5jx0qVk3F6R3KHrjO6JtIBjiFokyFgURZY6I7on5rmvChikazkz27vt0blXeuuLJHEFtDWHqnuhST07tHmQGyi6+erj+YhuGhPj/g8PSl4pZ9pmnz3HKPZH8GcYQ65b49hVwCVoCgPdlw==;3:3lQNNWUhS/z5d7TWHMqpvaI/xPD8fVKnNRs1JKI7cwDdsGHWrn5TTVfo0jOotdqis79N02RDMD1h0ooKVn756ccnq9yztoh104eKDP+QQLwONX3o5C5HbF1PtMLe+MyV;25:DLsl20gEnSgYTGszqQH6IzVruk76XziUhGoa32fZdoRv9Ve4m3EeztKxlsiwkVqkJ23dA2+YyXe0ytabHD1bzMnr9PipQ2qGW5j4PE9AGUnUwXFSLS4StJHcnQuWOKXKcI3ERjYf9Efedt23ZAKJDc+dhAHZi1H+cRDndedp7IPeZNUJ85eETUwhu72QTY4e1IjIwv+p4Lyl9lTlXgk42E40AJRNc4JGaIjO43jWcpIKo6d+XabFUGgOr8Mpxkwi;20:DRy2PWzl6jwjYVOVNLE+XjtLz4cZyLw1FtQSohv4Zh3YDCtmACYq97wm8Sp64LLOvt07cBKXIKx9n/KxRm6IOHcaLziqOMN6LL3bvKXzGI8lHqDYjNZU1rAUmEbwkWd/TKUdx6kf+dW9ttr7RgwVS/fKsIp3pHpJYXV/RmEJ/kKl1UZQmMD0qn2LM7siAvu3+X9JXjK66lMI2+N4e05fz2JvZuZVWQrUvvZAvt7kJgQnVgQ2AJ1aN7h2T+zNuKc9 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DB4PR08MB0141; X-MS-Office365-Filtering-Correlation-Id: 07a23a70-2ca7-4ac5-974f-08d31d285549 X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(180628864354917); X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(520078)(8121501046)(3002001)(10201501046);SRVR:DB4PR08MB0141;BCL:0;PCL:0;RULEID:;SRVR:DB4PR08MB0141; X-Microsoft-Exchange-Diagnostics: 1;DB4PR08MB0141;4:z5sOtwKOiHjtocmWcr2GIltTkTCvcg/qhtDe0zJg7+JSLJEztVHQNyzhmzRzTTf4MFViLWPoC7unltB6l0zCQQjg6OHpLqEE2xnoJtGxZWDL4poj6Rz3M8ETJEulUJPd3VoAJQLuUcWidtSq0tclzcpir/B2NW4pKkqxvHLe9XAyTh9yJH3HnJrUgOUNW3j4GQ2fM4F17m0tDIM89J7NOP8NOlSpIB8q5Tx29TeNXOhsMq+UtteBw0GLsrrjQJlK+xXZK/ZaApNRQ+zOBZoVaC3ryKzlZOxsg9dHqZAe+ABW4A/Zc+zdAMSPH9zp/69KSKKGDRACcdgL1r4sgUj+pWO1x9NZOF2S7CEnrLHvBQVqgtGxh4zbVjb05sGcmgFCChAPwO9WdKFsmMCzseF6oyHWS+FOoX27fKt22d9USmmtkKKCOv/H8GtFSGBTR64V X-Forefront-PRVS: 08213D42D3 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(6049001)(6009001)(164054003)(189002)(479174004)(24454002)(40434004)(199003)(81156007)(36756003)(86362001)(575784001)(80316001)(76176999)(54356999)(87266999)(92566002)(65806001)(66066001)(65956001)(1096002)(65816999)(59896002)(47776003)(2950100001)(101416001)(19580405001)(19580395003)(97736004)(50466002)(4326007)(2906002)(5001770100001)(5001960100002)(6116002)(586003)(3846002)(5890100001)(33656002)(189998001)(64126003)(5004730100002)(99136001)(5008740100001)(23746002)(40100003)(83506001)(122386002)(106356001)(42186005)(105586002)(50986999)(87976001)(77096005)(4001350100001)(7059030)(217873001);DIR:OUT;SFP:1101;SCL:1;SRVR:DB4PR08MB0141;H:[10.1.207.26];FPR:;SPF:None;PTR:InfoNoRecords;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;DB4PR08MB0141;23:7rDnc42TKlU8MUJyevhvsy2bjYJ4oIfyGICvs?= =?Windows-1252?Q?BYOMOL+/4xTNEIEQlhuIl6o9gLBU5voLpYnEXZhrfK2C7IKAQ+5w3N7h?= =?Windows-1252?Q?b1xEx7Qfm4AwEFtsneLbH7uiIqcDFTBoUypmLxqiF+jG9VCfUYlz9Gb8?= =?Windows-1252?Q?JBIld1x3froGg/mVUoXEE6XC992Ej1lwcRdqCc5mKX2+KqqYfAX4LgZD?= =?Windows-1252?Q?n+5treXeRTyZaQJDBQt9UKX4pTW+sdYhSnTY9a+U/N1QMsNLnjqg3GMq?= =?Windows-1252?Q?E+1IHWG+NIVFLT9EletbATfWSNZ0FHCijCRgwjOr7LfixA+rVnSBDqJ2?= =?Windows-1252?Q?vKLxeQJCS/mWy3+aTQrjcS1XUbo8BnSGxsBjbNkK+XQSIiHGfYn5m/KJ?= =?Windows-1252?Q?BvjJbRH2GgjHvskfTb1ctxL0aWP7kLpWvUtfrJI6YpJkwAjbGQSApvDf?= =?Windows-1252?Q?wS4sa2vnFRHrEPHLBCyPIglr8sSolL1opX71+8dSuXrYKYI+0c5tfls4?= =?Windows-1252?Q?e5W/gU2p6G/K/IIyA2jHMHDsrFi3JG7FZpFo0jh4ayC+/x2LH2aDlSaZ?= =?Windows-1252?Q?vPepNAQT3+1DBJHiLjUJ8Znom29cppRRB9FCmtFUpWwjtXB2xnYybEqL?= =?Windows-1252?Q?rkdbJAHMN+TmYuGML6q0Ct+rKUAQqqCnoHrzx+mQIDJODQfyT99JWTtQ?= =?Windows-1252?Q?k3vYaeSvdrwm5jBIZYitPosdMqqdRTacmLszYPBBCa/CvY5M5aFhrh+K?= =?Windows-1252?Q?op3gssc4ZVgdypJplL/kZzr21ERHA1IXNJxpmnUbjQo7DBQhSwu8ShEe?= =?Windows-1252?Q?n61kENmvucRl2FOAny+lVDZoNedEVRJP95YiTDVPo2AHXF5L8RNbC1Vy?= =?Windows-1252?Q?gUemLZJa6QpgQO8qEfXsY0XBbEYk8CB/LXtjOEpCrTZgdlArBpFzwBup?= =?Windows-1252?Q?W7RQoXgWzSPYuc+ZSeHDaX2AQ6yBo/WnTsEIWeWDKLjhvEPveaYFCHul?= =?Windows-1252?Q?f6k/jQqZjEYoJ+aUxLBBN1aECZb7KsaQx5rNACHxYYTerAekLElU01FY?= =?Windows-1252?Q?AowTrSxaFqplDwYssGnZW6QEcndi2S0aAI7856VuxgJMxGHm593Rc9o6?= =?Windows-1252?Q?NFdxkPmdGgcn+pSTj5BEbM9JE3F+bYLE177T2dlRceQkMywPhnhELL/t?= =?Windows-1252?Q?sOmEdQOZ8tmVFvEr7Ns+TNzUFVO216gxj895YA7luS7BUvYE6zdcG+DB?= =?Windows-1252?Q?T9NmmBlTMTgTfxzQwjLBioB72DpBP+6lwZvg0MrmD0yfST7AW2zVMNcu?= =?Windows-1252?Q?vG/rQj4F8AcHqImxm6Ms/GCJ2NjgPpDIC0ukkpM3ziyfHAimK4ioDOGU?= =?Windows-1252?Q?+8QjcJ1RTq3sRYyJupe+nUGguIeFWSCE1WRpREyW8WL+p3BhfCDzPSsu?= =?Windows-1252?Q?uRbIHBo8Sg1fZK1B/8qoL3qfmG8A+khLSox2GFl1b7YE0dUao857aYek?= =?Windows-1252?Q?8N9isLdWWEbHSfGueF/4+BZomkQphMDWDytRKN43tfv+YoD7S1IrzdoZ?= =?Windows-1252?Q?LpXybLqyMt+yYg=3D?= X-Microsoft-Exchange-Diagnostics: 1;DB4PR08MB0141;5:Lmo+gD4B6+IVElO9GhCira2Tbul347Q8KQEvNkCTB4LTsNEYRqJZKrbzcWFBYkE9iZWJSd0OYQF9hgMndeZgqhsH0BUuwSTai8T57OxzNBxB2CYDOWtI70EuTPPNW+PmPw+hef+xYfS1Awqj9M4eDA==;24:aRT0T+WjQjsaxZHNKgaAGQ7dUr7SRXRFHfX/KnqRmB+HOilHE+wjqa5+xapHsUmj1N+6bfrRsAtojXVhpsoV4XPGqEI699zqbL/qLTUGW90=;20:54d5mGfnQrkITL8Al8ZF+KSW0ucmiIPxhNo/TTlhoDhHjlywCzRkZ+JaxhlIc6ZE+vtBLAw5FnPXLYKu62G6bH09lmwAW5rQOrMSG2/Y8omLP0YTVXtBZv5vaHd6B+EDgaTPJoq7LaxypTrEmsN6aM5m6xmkqa39fg93trMIhLE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Jan 2016 21:19:04.5999 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR08MB0141 X-MC-Unique: ueqx2awySXmwLoh_apGPmQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Frederic, On 13/01/16 16:01, Frederic Weisbecker wrote: > Hi, > > Most of the remaining nohz full work is about making the scheduler > resilient to full dynticks (such that we can remove the 1Hz one day). > Byungchul Park started interesting work toward that with cpu load > updates in nohz full. So here is one more step forward. > > Patches 1 and 2 concern both dyntick-idle and dyntick-full. The rest > is rather about full dynticks. Note that this isn't complete support for > cpu load in nohz full, we still need to think about a way to make > target_load() able to return up to date values on full dynticks targets. > > git://git.kernel.org/pub/scm/linux/kernel/git/frederic/linux-dynticks.git > sched/core > > HEAD: f1d7d0f5382be3819490a859313f692f142dfb74 > > Thanks, > Frederic > --- > > Frederic Weisbecker (4): > sched: Don't account tickless CPU load on tick > sched: Consolidate nohz CPU load update code > sched: Move cpu load stats functions above fair queue callbacks > sched: Upload nohz full CPU load on task enqueue/dequeue > > > kernel/sched/fair.c | 306 ++++++++++++++++++++++++++++++---------------------- > 1 file changed, 175 insertions(+), 131 deletions(-) > I noticed during the test of these patches on a NO_HZ_FULL cpu, that the rq->cpu_load[] values can be abnormally high. This happens w/ and w/o your patches but it happens way more w/ the patches applied. It might be related to commit 59543275488d "sched/fair: Prepare __update_cpu_load() to handle active tickless", at least the following patch cures it for me. -- Dietmar -- >8 -- Subject: [PATCH] sched/fair: Avoid unsigned underflow in __update_cpu_load() tickless_load, which is rq->cpu_load[0] in the active case, can be greater than rq->cpu_load[i] (0 < i < CPU_LOAD_IDX_MAX) which then leads to an unsigned underflow when calculating old_load. In the NO_HZ_FULL case (tick_nohz_full_update_tick() -> tick_nohz_restart_sched_tick() -> update_cpu_load_nohz() -> __update_cpu_load()) with pending_updates > 1, rq->cpu_load[i] (0 < i < CPU_LOAD_IDX_MAX) can end up with abnormally high values: Fix this by only assigning the difference out of rq->cpu_load[i] and tickless_load to old_load if the former is greater, otherwise set it to 0. Also bail out of decay_load_missed() if it is called with load = 0. E.g. running a pinned 50% task (w/ heavy tracing) on a cpu in NO_HZ_FULL mode showed these max values for rq->cpu_load w/o this patch: max(rq->cpu_load[0]): 738 max(rq->cpu_load[1]): 626 max(rq->cpu_load[2]): 10133099161584019 max(rq->cpu_load[3]): 42361983994954023 max(rq->cpu_load[4]): 80220368362537147 W/ this patch, the values are back to normal: max(rq->cpu_load[0]): 769 max(rq->cpu_load[1]): 618 max(rq->cpu_load[2]): 607 max(rq->cpu_load[3]): 602 max(rq->cpu_load[4]): 599 Signed-off-by: Dietmar Eggemann --- kernel/sched/fair.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9deda2ac319f..4bf8f7c2c8b7 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4276,7 +4276,7 @@ decay_load_missed(unsigned long load, unsigned long missed_updates, int idx) { int j = 0; - if (!missed_updates) + if (!load || !missed_updates) return load; if (missed_updates >= degrade_zero_ticks[idx]) @@ -4346,7 +4346,10 @@ static void __update_cpu_load(struct rq *this_rq, unsigned long this_load, /* scale is effectively 1 << i now, and >> i divides by scale */ - old_load = this_rq->cpu_load[i] - tickless_load; + if (this_rq->cpu_load[i] > tickless_load) + old_load = this_rq->cpu_load[i] - tickless_load; + else + old_load = 0; old_load = decay_load_missed(old_load, pending_updates - 1, i); old_load += tickless_load; new_load = this_load; -- 1.9.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.