From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A6F48C04A6A for ; Wed, 16 Aug 2023 02:49:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S241368AbjHPCtS (ORCPT ); Tue, 15 Aug 2023 22:49:18 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44170 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S241362AbjHPCsu (ORCPT ); Tue, 15 Aug 2023 22:48:50 -0400 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.100]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6CCBF212D for ; Tue, 15 Aug 2023 19:48:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1692154129; x=1723690129; h=from:to:cc:subject:date:message-id:mime-version: content-transfer-encoding; bh=4Skr/d/Gsy3Lv09RBnrhYA65xNjEbgJO9BhEyIPx5uU=; b=bWViVOIrPFA1VVHqBEMj8zUFA2TwinpuNRDsTmEeowOAxtyeFE6QAOMB q3ixA7s0xwfT9FBnr29NQNO6OHrhNfT16bWcVu0aIKLZYzg2T1fmMbZ4T nPQ9BbRmXgpCWEr2BtfAL+UKyhkxgZgNsoRDnlW7bfYpXQPc26ewd2MOu Tu0/55Hli+qMHOS/anPBhV5e90jGufqGIrbETDGvLNOakfRkwgvCglIMJ WjkFGYFRuOG98GgWpU1OhRhfH0cUHHvvPF4VC06Gnh37zrwQUxihsUce+ gSG+hQOQ7Q5b59W8EmcH99ZtnOtI7yao+E0xquF+WM4kxzPxUyyi53YES A==; X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="438770432" X-IronPort-AV: E=Sophos;i="6.01,175,1684825200"; d="scan'208";a="438770432" Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga105.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2023 19:48:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=McAfee;i="6600,9927,10803"; a="734040502" X-IronPort-AV: E=Sophos;i="6.01,175,1684825200"; d="scan'208";a="734040502" Received: from ziqianlu-desk2.sh.intel.com ([10.239.159.54]) by orsmga002-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Aug 2023 19:48:42 -0700 From: Aaron Lu To: Peter Zijlstra , Vincent Guittot , Ingo Molnar , Juri Lelli Cc: Daniel Jordan , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Valentin Schneider , Tim Chen , Nitin Tekchandani , Yu Chen , Waiman Long , Deng Pan , Mathieu Desnoyers , linux-kernel@vger.kernel.org Subject: [RFC PATCH v2 0/1] Reduce cost of accessing tg->load_avg Date: Wed, 16 Aug 2023 10:48:30 +0800 Message-ID: <20230816024831.682107-1-aaron.lu@intel.com> X-Mailer: git-send-email 2.41.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Nitin Tekchandani noticed some scheduler functions have high cost according to perf/cycles while running postgres_sysbench workload. I perf/annotated the high cost functions: update_cfs_group() and update_load_avg() and found the costs were ~90% due to accessing to tg->load_avg. This series is an attempt to reduce the overhead of the two functions. Thanks to Vincent's suggestion from v1, this revision used a simpler way to solve the overhead problem by limiting updates to tg->load_avg to at most once per ms. Benchmark shows that it has good results and with the rate limit in place, other optimizations in v1 don't improve performance further so they are dropped from this revision. Aaron Lu (1): sched/fair: ratelimit update to tg->load_avg kernel/sched/fair.c | 13 ++++++++++++- kernel/sched/sched.h | 1 + 2 files changed, 13 insertions(+), 1 deletion(-) -- 2.41.0