Received: by 2002:a05:6a10:22f:0:0:0:0 with SMTP id 15csp61924pxk; Tue, 15 Sep 2020 17:52:35 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzzbSsm8F77itlSTrRapZW5F22Y42b3iJa15rGYyHM7A5DgBy6kMRN9mV2EZksKrPvy6bSD X-Received: by 2002:a50:fa88:: with SMTP id w8mr25384119edr.179.1600217555212; Tue, 15 Sep 2020 17:52:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1600217555; cv=none; d=google.com; s=arc-20160816; b=o8Fzp3h8t3bX0YFz3jqMJ3g8tewLB0EYbqZQf/skfihcAdCPfdKHzBIvIOG5EeFCyR 5YX4l4ixiPBvuLX4xj0jYNf2MMFtdsaYOH2ETRlc14Uk4G6WmU/BNO0qDhTJmAuTcQoU 2G3edNDecZH1GQbpw3773/d1Z1wGtBsmfpWcouuJ5uigDj/UiToHzne6458yyVDbseis 4Ij5A0DLHy6ToafcmGEYh/MB9aTwzu54M5bIClKxNrhKYlWVLETfKvVBGKgiaGb2SOlt SBB0O1nRzGMmofCFb8ye8yOwnCmf4y9xFkJqvSl5yBzRgfe3K21y0+m4Fjue4vK+yqFY S+nA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=6BTH4hYV4B4dr8UvozyKIS6RwtFNWec8KfhyM0AE6Qc=; b=VfNprbLuK+B5QFYmdrNxl4UShg14+kn0AFhmAsk8KlW36ixSITjeFZWnC/ou0Ph4X9 aAXNY/dQ4W4A9UhMsoPSGZo2qV+jM0D16zhJMj/tM5gWmSv7mM/7w09fWKfsnL9XIEU6 l1hK4trMUBhSywT/DYlxbK7NtfG7sP5Az2Kc4JqvuanKoW61obm1pBI75+v/hvcU2E5W UOHspp8d8ip5kIaOH1Ov7wdFf3RJKh6sqRipbBuTaXMeIIiGUAIKFeQEFXxARrbuK5K5 oGV5gfbtAaQThOpqiNFfsNTgx9HiaCbG8pRXTi7UUsAAWRyskwMQV9rvXuoxbO2SctFj U41w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hOwgrJB4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id ay1si10944392edb.440.2020.09.15.17.52.13; Tue, 15 Sep 2020 17:52:35 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=hOwgrJB4; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726373AbgIPAvk (ORCPT + 99 others); Tue, 15 Sep 2020 20:51:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:35534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726376AbgIOLg3 (ORCPT ); Tue, 15 Sep 2020 07:36:29 -0400 Received: from mail-ot1-x344.google.com (mail-ot1-x344.google.com [IPv6:2607:f8b0:4864:20::344]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 7D355C061788 for ; Tue, 15 Sep 2020 04:36:28 -0700 (PDT) Received: by mail-ot1-x344.google.com with SMTP id o8so2901568otl.4 for ; Tue, 15 Sep 2020 04:36:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=6BTH4hYV4B4dr8UvozyKIS6RwtFNWec8KfhyM0AE6Qc=; b=hOwgrJB4oFdOSRj3vyxBUqBo2w70rKKrtDqGxTxuPUHxBSRKqAfaYTSiTsTVjL3QWg +SxuVlbaeUK01wBEpy1a7Mv4cN/GW8ibCuDmTv+5/5LSlEakqyfLwzpHQLv2/DYJYekt 7V9H3bomGcTmIHdO+0J+J20rUugFpv7WctV0SQ/HQ32ceAPS4qf5WU64e35bvSM3A8eD zQ6tpOg1hcaoSLhevNSvjWxGwHosppuhr52e9hUxVt0sZcvvi/bsjRSN/1Q5mngOfIlz sj7gq0+zdDflbqY7ImsDJxRW2UTMjZpMvSdV7JpSnoWFITXXb/GQgFvqISagP6yoJkS2 OQHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6BTH4hYV4B4dr8UvozyKIS6RwtFNWec8KfhyM0AE6Qc=; b=nfCEorowKtyxgf3B8IFOzduIsX+/Pe4U0QB/n1cKsqn5ocinOIQ+E9RwZ1Xs07bs0p VKQkVyC7shcuaWk5AJ8OCwITFFEWA6B9f8Ij2d3T0iKUlwUSKzs2n4M3+x/xe24vy/gz /r9vaZX9XX0d+c1xwHfvseVOKO1f6BEgf8aDnrqnGf9PcckmRnnBem+dWu+DJHF8kjyD 5lUQ/YOVo54tRY5xqw1UUt8T9JmM0SqgIlkCdPFGcmdEZmh5IoQxvYKyW48dE4JQRpRk Ix89rhjoNYKwYTFUbLG7iW7TJ+Va6fSt8EuZM1Nr19Y6Ymoh/XdiUmA+bH+UBUblWfNC lIuw== X-Gm-Message-State: AOAM530tBHUBlKRBFda9G/JpgQ/6zLUd5KDLbbU+5wpjMRyE78wbDBWD fcevi88CLlFYXkzkST7TfabSng0OAPTr943O0F4= X-Received: by 2002:a9d:758c:: with SMTP id s12mr11873480otk.237.1600169787933; Tue, 15 Sep 2020 04:36:27 -0700 (PDT) MIME-Version: 1.0 References: <20200914100340.17608-1-vincent.guittot@linaro.org> <20200914100340.17608-5-vincent.guittot@linaro.org> In-Reply-To: From: Jiang Biao Date: Tue, 15 Sep 2020 19:36:16 +0800 Message-ID: Subject: Re: [PATCH 4/4] sched/fair: reduce busy load balance interval To: Vincent Guittot Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , linux-kernel , Valentin Schneider Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, Vincent On Tue, 15 Sep 2020 at 17:28, Vincent Guittot wrote: > > On Tue, 15 Sep 2020 at 11:11, Jiang Biao wrote: > > > > Hi, Vincent > > > > On Mon, 14 Sep 2020 at 18:07, Vincent Guittot > > wrote: > > > > > > The busy_factor, which increases load balance interval when a cpu is busy, > > > is set to 32 by default. This value generates some huge LB interval on > > > large system like the THX2 made of 2 node x 28 cores x 4 threads. > > > For such system, the interval increases from 112ms to 3584ms at MC level. > > > And from 228ms to 7168ms at NUMA level. > > Agreed that the interval is too big for that case. > > But would it be too small for an AMD environment(like ROME) with 8cpu > > at MC level(CCX), if we reduce busy_factor? > > Are you sure that this is too small ? As mentioned in the commit > message below, I tested it on small system (2x4 cores Arm64) and i > have seen some improvements Not so sure. :) Small interval means more frequent balances and more cost consumed for balancing, especially for pinned vm cases. For our case, we have AMD ROME servers made of 2node x 48cores x 2thread, and 8c at MC level(within a CCX). The 256ms interval seems a little too big for us, compared to Intel Cascadlake CPU with 48c at MC level, whose balance interval is 1536ms. 128ms seems a little more waste. :) I guess more balance costs may hurt the throughput of sysbench like benchmark.. Just a guess. > > > For that case, the interval could be reduced from 256ms to 128ms. > > Or should we define an MIN_INTERVAL for MC level to avoid too small interval? > > What would be a too small interval ? That's hard to say. :) My guess is just for large server system cases. Thanks. Regards, Jiang