Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 13 Dec 2022 13:46:26 +0800
From:   Chen Yu <yu.c.chen@intel.com>
To:     Josh Don <joshdon@google.com>
CC:     Yicong Yang <yangyicong@huawei.com>, <yangyicong@hisilicon.com>,
        "Vincent Guittot" <vincent.guittot@linaro.org>,
        Joel Fernandes <joel@joelfernandes.org>,
        Honglei Wang <wanghonglei@didichuxing.com>,
        "Peter Zijlstra" <peterz@infradead.org>,
        Tim Chen <tim.c.chen@intel.com>,
        Mel Gorman <mgorman@techsingularity.net>,
        Juri Lelli <juri.lelli@redhat.com>,
        "Rik van Riel" <riel@surriel.com>, Aaron Lu <aaron.lu@intel.com>,
        Abel Wu <wuyun.abel@bytedance.com>,
        K Prateek Nayak <kprateek.nayak@amd.com>,
        "Gautham R . Shenoy" <gautham.shenoy@amd.com>,
        Ingo Molnar <mingo@redhat.com>,
        Dietmar Eggemann <dietmar.eggemann@arm.com>,
        "Steven Rostedt" <rostedt@goodmis.org>,
        Ben Segall <bsegall@google.com>,
        "Daniel Bristot de Oliveira" <bristot@redhat.com>,
        Valentin Schneider <vschneid@redhat.com>,
        Hillf Danton <hdanton@sina.com>,
        Len Brown <len.brown@intel.com>,
        Chen Yu <yu.chen.surf@gmail.com>,
        Tianchen Ding <dtcccc@linux.alibaba.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] sched/fair: Introduce short duration task check
Message-ID: <Y5gRsnLQLlzugB4I@chenyu5-mobl1>
References: <Y4r/iuqyLG4MOK4d@chenyu5-mobl1>
 <3A5DA66F-4330-4FC4-9229-998CF98F663E@joelfernandes.org>
 <Y42uH5fglluWYOm7@chenyu5-mobl1>
 <CAKfTPtA61DDk-VbNDvAycp8Et5fTwaOS=Q3559rBF7QDHDpJfQ@mail.gmail.com>
 <CABk29Nuc+VVOpAwFsbBo+OppayszebT29Hadc8qK-xeyZpY6NQ@mail.gmail.com>
 <Y5CiN010QAwklahh@chenyu5-mobl1>
 <e0b20fe3-6528-41ca-f53f-d78e76cd122a@huawei.com>
 <Y5c7oTIRIQYYkdW1@chenyu5-mobl1>
 <CABk29NvsBbqop20Z8-mdnZpto+Znc_+93OK9dsVMcimsSOf1xQ@mail.gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABk29NvsBbqop20Z8-mdnZpto+Znc_+93OK9dsVMcimsSOf1xQ@mail.gmail.com>
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?J7EJuT8qMPm2iu2X/4NzqB60BA+pDExgV2kes78uNy1OA4GCkaNh8ncIKRiW?=
 =?us-ascii?Q?wQUK8rfX4sorm+ZwkmDMhYzP3gP9y8zw8kJkzFAxBgE0F8PK4sf5O7yuHrX/?=
 =?us-ascii?Q?ZKIr7R08TcKvDdXsERKnG9EB0nLOszFSooqqivDlaJpE5Uu8vWRaWqsRzdgy?=
 =?us-ascii?Q?lq/FJjMGPLGBFmo5dez2qT47RiLYEz5RTmTzxoEelu1a053hG9DgjhlUYs7N?=
 =?us-ascii?Q?Xma2yGyYqmwoz0Ng1hP/hrIZ2JALbPCF46cJD1TqCYmMQc5MTcirG6JiH5yL?=
 =?us-ascii?Q?grih36WLXtunduWYlsqBk5z0N0yL3CnXU2xPAnyajs6V47D3pAcv1RGpsxnP?=
 =?us-ascii?Q?sWJMUQMsLW6N5KHOgcS5/A8i81IR4dRANnJniPs1kFOIWmECeH9XTnjxl4NY?=
 =?us-ascii?Q?4h2Bn+QVZ00KrzHpVz6IvjnFO5ITECeYBxa3CeL8tM8UGYswJV1O7UvANHfb?=
 =?us-ascii?Q?pHEdI2PAVQlZ/Ll54LZunT7Jb42J06Bnu784qpqkJONFCL2ltqhhc6NOqq1a?=
 =?us-ascii?Q?Nuf0T2JqdSWSktFkMGegi2U5cc7n7lyA2hW9il6efruoDkMRYAdudHDW4Mxn?=
 =?us-ascii?Q?eemkv5pZFdasst7yX5dqPMFTOc1S2OVxikxljoohCqrOvN/QmQxWqCySXBip?=
 =?us-ascii?Q?6qjoGvLBq8KvYbvOLgcw3kJcewu0/ZtlS86a8AtABFcUv7qLiII5mNoiv+hz?=
 =?us-ascii?Q?ryBayeQvYaEUTp6SuOTxIYSrM5tCheRpQ2Kexv2uJkF2Q8JCQJR/4tcp/IbW?=
 =?us-ascii?Q?6rZQwLPo+S9sYeGBzB0Z7Eb1k6TwJDBRq3k+JiRzdEAknFzubxKMFaqyX1+b?=
 =?us-ascii?Q?tx3x3PiIyrTkyVLNQVWQpvjqI7ljyhJNXP3SefR5XIhoDBiHL657hsuG+u5f?=
 =?us-ascii?Q?ln0lz5d8++kUVsMw5siJcBKbtaT+NMvS5gPZjTDskWps77/ta4yIujyndc9/?=
 =?us-ascii?Q?1Jl2nRwS+1UUVQQIngqyP5w81zBHW76SPS2CGZHTdBfmn5qwrxGMu4KByCae?=
 =?us-ascii?Q?XYE7bAO2U9yqmz+e3iu4rxEzxktTKokd5cRUl8AYbXTO7JLFGaNUtYHYVBE1?=
 =?us-ascii?Q?YKhc5imj9nOSNnY2psDNlkPZ0XzrgtdxRkhpBDJGGMT0mFb7SiU4GOWl3gAV?=
 =?us-ascii?Q?vrwW2D6jFzjy2Pe4V0E7F4lHNF4BM9uhEuHp4AmLsbX8rqLIh4SNJ4rqCS9K?=
 =?us-ascii?Q?h+tmTap/TyijWkzpkl28CIxiKRIXUY+EJFnwcc/j1NFgQfUaI14T1YYlLHTj?=
 =?us-ascii?Q?9SmBL2SHdrSvHU8toEe/T/WLkF1n2C+zBs4VK5Zxpsbpmytu0ZIzttGS0QKv?=
 =?us-ascii?Q?10XgeXik1t/cXXHkYcDrF/uAabUuGmFMYxSdRYtEA6bPsHoN3uFsRz7DgNH2?=
 =?us-ascii?Q?4o29YJe3C8vXEI+4aEyIEacY7BLpdDTZdLwnwoSwYIlDMI+hde1D9dubLqAS?=
 =?us-ascii?Q?Ece6O22OnnMZYMzMbuk3HDlvrArssMn+pwFQeb0naN5aG36aQSNCMiKf6cyi?=
 =?us-ascii?Q?/boGkCKdNkeJ0mFc8ExXaMq4lvfSgAtISqpwJIvTVhkgC8Y23O/t+xfXQ2im?=
 =?us-ascii?Q?IFTzqjnxOp+gy0RfPCyX0sYqQyvN63Ef+EeVpWwf?=
X-MS-Exchange-CrossTenant-Network-Message-Id: fe36de0f-7e59-4e37-d342-08dadccd6dd6
X-MS-Exchange-CrossTenant-AuthSource: MN0PR11MB6206.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2022 05:46:51.2432
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 46c98d88-e344-4ed4-8496-4ed7712e255d
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: oYhm/V8kj4+Yjly5/I3+fEdJ+K+F0kGJt/x0/VUkyMqeyzke0pA6zQ5O0oYa+5xM8k01GfoVObtFlqVoILg2sQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN7PR11MB7017
X-OriginatorOrg: intel.com
X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,
        DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,
        SPF_HELO_NONE,SPF_NONE autolearn=ham autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

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.

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