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 32963C4332F for ; Tue, 13 Dec 2022 10:07:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235076AbiLMKHJ (ORCPT ); Tue, 13 Dec 2022 05:07:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49328 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234753AbiLMKHB (ORCPT ); Tue, 13 Dec 2022 05:07:01 -0500 Received: from mx5.didiglobal.com (mx5.didiglobal.com [111.202.70.122]) by lindbergh.monkeyblade.net (Postfix) with SMTP id 5244D1A811 for ; Tue, 13 Dec 2022 02:07:00 -0800 (PST) Received: from mail.didiglobal.com (unknown [10.79.64.13]) by mx5.didiglobal.com (Maildata Gateway V2.8) with ESMTPS id 62240B0069A26; Tue, 13 Dec 2022 18:06:58 +0800 (CST) Received: from [172.28.90.63] (10.79.65.102) by ZJY01-ACTMBX-03.didichuxing.com (10.79.64.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Tue, 13 Dec 2022 18:06:57 +0800 Message-ID: <2a54f264-de3d-d5a3-941a-016ed2cfea0a@didichuxing.com> Date: Tue, 13 Dec 2022 18:06:50 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [PATCH v3 1/2] sched/fair: Introduce short duration task check To: Chen Yu , Josh Don CC: Yicong Yang , , Vincent Guittot , Joel Fernandes , Peter Zijlstra , Tim Chen , Mel Gorman , Juri Lelli , Rik van Riel , Aaron Lu , Abel Wu , K Prateek Nayak , "Gautham R . Shenoy" , Ingo Molnar , Dietmar Eggemann , Steven Rostedt , Ben Segall , Daniel Bristot de Oliveira , Valentin Schneider , Hillf Danton , Len Brown , Chen Yu , Tianchen Ding , Content-Language: en-US X-MD-Sfrom: wanghonglei@didiglobal.com X-MD-SrcIP: 10.79.64.13 From: Honglei Wang In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.79.65.102] X-ClientProxiedBy: ZJY03-PUBMBX-01.didichuxing.com (10.79.71.12) To ZJY01-ACTMBX-03.didichuxing.com (10.79.64.13) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2022/12/13 13:46, Chen Yu wrote: > On 2022-12-12 at 10:17:35 -0800, Josh Don wrote: >>> BTW, I've changed the threshold to (sysctl_sched_min_granularity / 8) in my next >>> version, as this is the value that fit my previous test case and also not to break >>> the case Josh mentioned. >> >> Do you mean a hardcoded value of some number of micros, or literally >> sched_min_granularity / 8? > The latter. According to the test, the average task duration when system > is under heavy load: > 6 ~ 9 us for netperf > 7 ~ 70 us for hackbench > 7 ~ 8 us for tbench > 13 ~ 20 ms for schbench > Overall the duration of the micros are quite small(except for schbench). > The default sysctl_sched_min_granularity is 750 us in kernel if no user > has changed it. Then 750 / 8 = 93 us, which is close to what you suggested(100us). > On the other hand, if someone changes sysctl_sched_min_granularity, > then '8' can be viewed as log2(256). That is, if there are 256 CPUs online, > and the sysctl_sched_min_granularity is changed to 750 us * log2(256) by > the user, we can devide the sysctl_sched_min_granularity by 8 in case the > sysctl_sched_min_granularity is too large. > Hi Yu, Seems there is a min_t() call in get_update_sysctl_factor(). In most cases, we'll get 750 us * (1+log2(8)) = 3000 us in default due to sysctl_sched_tunable_scaling is set as '1' default. (Correct me if I misunderstand). For the value in production environment, I've seen 10 ms and 3 ms in different place, FYI. Hope this help. Thanks, Honglei > My concern of using hardcoded value is that, this value depends on how fast > the CPU runs(cpu frequency). The value I measured above is when the > CPU is running at 1.9Ghz. If a CPU runs faster, a hard code value might not > be appropriate and could not be tuned. >> I don't think the latter is necessary, and >> indeed can lead to weirdness if min_gran is too small or too large. I >> don't think the concept of what a short duration task is should >> expand/contract with min_gran. > The value of sysctl_sched_min_granularity might indicate how long the > user would like a task to run at least. If the user enlarge this value, > does it mean the user wants every task in the system to run longer? > From this point I found connection between the the definition of short task > duration and this value. I'm open to changing this value to a fixed one, may > I have more insights on how this value would be set in production environment? > > thanks, > Chenyu >> >> Best, >> Josh