Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp656369imu; Mon, 5 Nov 2018 06:55:02 -0800 (PST) X-Google-Smtp-Source: AJdET5fDAfVn7mqp25yFkE9yQH2BLjDd4vHvczkxgrb1vFXw8liGO8DHbu2obA6pG8nlLCwtLNza X-Received: by 2002:a17:902:7797:: with SMTP id o23-v6mr9942218pll.30.1541429702792; Mon, 05 Nov 2018 06:55:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1541429702; cv=none; d=google.com; s=arc-20160816; b=PhYPokdBg4tHVHn/BFBMLNclKg2ckzcocqITzdTVkYF9a8IrMjEdDjj6DUSOqyO7oC YNCTFPVnBj8KRQ9jjNcpGjStYn7VxDUfFRbJBGLbn6c/LWOIaf68zfa8OewwonGZGi1w AI/cFnVwo80dSvt2yRx7IHW535/8NhCEdTYMVDa+vXDev4RSWzo5FrqMLORrbwl14iaW MsOV3oo43aQH6oyuBAbNeLsEMWGuJshXQFGXOFmf922jWEYGboM9v+pRN9wDw6T24nB4 c8s0dfagPutMHI9rOYLxcw44/9DpgySHHZ5We+GHO4Ln/ccnuCVdgGwVSQ8zYmtEbs31 XunQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from; bh=DNTHBsJkCvXHWSEgfyZha3/5v0jk0CEWTcjbD0XnImc=; b=H+ZX0XjuM07+KCb8bSFQAVG93HoJU5pEoywQeC1XZqmuBTRJzAEu4UxdNOWPbBC53/ 1OR975QIZGwk5vs0YCfY3BZ8F94mUs/4b0/LFAl9VAqmg50/0Ag51wynvo0kw9RayRH8 8b0fKToYiD6C9cOqleNzvDdXc3X9ILVCLDBgFh91kHt656bhioVWbzia3FI7Q15jiD6L pm1OdtT59iKn/vR/EbDGYa5ATAyiNaiaoLqB+l0deeYeKmnyd5M3qxFv/HTQgCSe6FQT VJIaBYLH1qaXD8WR911ZzUVvDsyQZHbk2iCf3xHaj/wwJb9lRnmuPvmd/HVLkwMRwmdd RVVg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a1si13362650pgk.495.2018.11.05.06.54.46; Mon, 05 Nov 2018 06:55:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729692AbeKFAOV (ORCPT + 99 others); Mon, 5 Nov 2018 19:14:21 -0500 Received: from foss.arm.com ([217.140.101.70]:45286 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726255AbeKFAOV (ORCPT ); Mon, 5 Nov 2018 19:14:21 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 5E922A78; Mon, 5 Nov 2018 06:54:16 -0800 (PST) Received: from e110439-lin.cambridge.arm.com (e110439-lin.cambridge.arm.com [10.1.194.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 4C6AC3F5CF; Mon, 5 Nov 2018 06:54:14 -0800 (PST) From: Patrick Bellasi To: linux-kernel@vger.kernel.org Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Quentin Perret , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Steve Muckle , Suren Baghdasaryan Subject: [PATCH v2 0/3] util_est regression fixup and cleanups Date: Mon, 5 Nov 2018 14:53:57 +0000 Message-Id: <20181105145400.935-1-patrick.bellasi@arm.com> X-Mailer: git-send-email 2.18.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This is a respin of: https://lore.kernel.org/lkml/20181030160947.19581-1-patrick.bellasi@arm.com/ rebased on v4.20-rc1, which addresses Peter's comments by also adding a couple of additional cleanup patches on top. Tests on a 40 CPUs Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz system still reports the ~10-15% Execl Throughput improvements after applying the first patch. Those benefits are not there if we remove the additional test on "current == p" which Peter was asking about. I guess the race condition described in the new inline comment I've now added could be the reason for the additional test being required, but I did not really verified that guess. I've just kept both conditions but swapped them since we will probably be more likely to call cpu_util_without() with a task which is eventually marked as task_on_rq_queued(). The second patch is pretty simple, while the last one implements what Peter suggested in the previous review. I did not used something similar to sub_positive, as suggested by Peter, just because in my tests that implementation seems to affect negatively the Execl Throughput tests results by reducing the speedup we get with the proposed version. Best Patrick Patrick Bellasi (3): sched/fair: util_est: fix cpu_util_wake for execl sched/fair: util_est: mask UTIL_AVG_UNCHANGED usages sched/fair: add lsub_positive and use it consistently kernel/sched/fair.c | 85 ++++++++++++++++++++++++++++++++++----------- 1 file changed, 64 insertions(+), 21 deletions(-) -- 2.18.0