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;
Subject: Re: [RFC 6/6] sched/fair: Add sched group latency support
To:     Vincent Guittot <vincent.guittot@linaro.org>,
        Tejun Heo <tj@kernel.org>
Cc:     mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com,
        dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com,
        mgorman@suse.de, linux-kernel@vger.kernel.org, parth@linux.ibm.com,
        qais.yousef@arm.com, pkondeti@codeaurora.org,
        Valentin.Schneider@arm.com, patrick.bellasi@matbug.net,
        David.Laight@aculab.com, pjt@google.com, pavel@ucw.cz,
        dhaval.giani@oracle.com, qperret@google.com,
        tim.c.chen@linux.intel.com
References: <20220311161406.23497-1-vincent.guittot@linaro.org>
 <20220311161406.23497-7-vincent.guittot@linaro.org>
 <Yji0twS4N+0b/Rs9@slm.duckdns.org>
 <CAKfTPtA8g-MJMPRM2R_Bfo9rGSyR3cYAUy_j5UrRM+SAB=Mm7w@mail.gmail.com>
 <Yjn8DohJ8CZ6pEvf@slm.duckdns.org>
 <CAKfTPtB4iV0Z40grV3w=WwpOUAZAgx_ZoBfvjA63H8Am-RYdNw@mail.gmail.com>
From:   Chris Hyser <chris.hyser@oracle.com>
Message-ID: <7139641b-5ca6-3799-9e41-72af894d02ad@oracle.com>
Date:   Wed, 23 Mar 2022 14:20:17 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101
 Thunderbird/68.2.2
In-Reply-To: <CAKfTPtB4iV0Z40grV3w=WwpOUAZAgx_ZoBfvjA63H8Am-RYdNw@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?eXRVUExpVzRrdnhNT2xXM2pBZGdjdzVwVGM0eWlGbkxQd3E5QkIvd3dIZmZl?=
 =?utf-8?B?NHJXM0JyWXY3c0l4NU4xSUVjcDFSZHF3cnRyRjU4NHZnQ0xreXlrazcyYVlL?=
 =?utf-8?B?QlZ2dTlzVVBwMjg5VnlOeVR3WkROSERqZjlSemg2SDdpaEJPc3BGYzBuTGxs?=
 =?utf-8?B?M2t1ZDhHejllUVdGV2Jaa3o4Kzl1dkMyR1o2aGZPUmpOS1FqSFl6QVFjL1E3?=
 =?utf-8?B?T1ZTYXFEYTZsRGRXbldIVkREY0pwWUptVlRnVXFWb0IvelU0K3hCUFJjNkZE?=
 =?utf-8?B?MkpzeS9MVjZLMnV4S1hJaFRodEtmNWtmZkkwd1l3RFlkalZucDIvaDdGVUFu?=
 =?utf-8?B?ckJRQk1wSTNMWUk5OXc5dG1TVENIbGNsSGlmRFpabkIxYnlXL2dXdnJsWWR6?=
 =?utf-8?B?aEljSHo3dTM1azY0WEkrei9tSmcyMGtuTE14RzVVczAvSVA4U0Yrelc5M241?=
 =?utf-8?B?ZDk3SWZMV2RCTW50enNFMXBEbHduaXJzc2IwdCtRcExTSlZnZkhWVHFoalY5?=
 =?utf-8?B?eW9PWEVHSDMrQTFqVCs5YkpMbHdKQ3lqQ2p0OHUzZXhhWVV3ZzNHT0o4bXpZ?=
 =?utf-8?B?V1BaMHQvWE0zZEFNcUpDcG1BYlVkWWFsVlRaVk1TTzVwa2pQNkFiSEdYOU1v?=
 =?utf-8?B?bC9Hd0JKUTZUeFgzL1VPbTl2WHZLRyt6eHpJVE83UzU2N29EWGpJSnhaa2s1?=
 =?utf-8?B?b2IzVzRvQ1VNeG5NNngzL3QzTDQreG1OdkkvNFoyejVVdGVrbi8xeFNyQjhW?=
 =?utf-8?B?anBsTThEQmtBbU5acEtLQWl0T3dMN2JFWjE1NXg0Skw3R2luekN6emExWlhV?=
 =?utf-8?B?Rkh2b3ZJaU1lRXpHU01hQlBMQmpFSmNFYTMvaW5taFFNdnhvdUduT0hYcGc2?=
 =?utf-8?B?TU4ybWg3S0ZYaW56cWprTjYySndxVzRoWGRXRkdNbThEb08vRit0aSs0Mi8v?=
 =?utf-8?B?K0hsYzFGYUU3R3FEMndDREFoeTNWcVBSRlZpR1RIZHVkSXJGQVRkWm8yUEs1?=
 =?utf-8?B?VGcwakJDSHpnUXpMZCs3TlZOTGw2ckxZYm9oK2tKeXYxTEN0VG9hTFlIenB4?=
 =?utf-8?B?SDlNOUJsbmFRLzNGZzBQZnlObjJZcjgrQnVvZkpDQkQxZGtoQ3Y0cHg0SDc0?=
 =?utf-8?B?UjdXeG5EcTZCQVloV093S2V2dE4vc0tzWkllSWhkVzFDRWxpY3F3UlQ1UG5B?=
 =?utf-8?B?WjR5U0VMUWdqaG5ERjZ2bEdtcW0wR3U4MmJSMTdmZjcwSXduMEwxK1RjSld1?=
 =?utf-8?B?dDF5NjBTOEg2aEIxQVBKSnpna1AyeXpiSS95ZE5xN3JlOVc3M2pId1B1T2Rk?=
 =?utf-8?B?azUxRTdlM1VlMVBEeFFxak80cGpmS0J4MUhmMkRzMEtRQkVwTE42eGNkWUVD?=
 =?utf-8?B?aVFQOVJzRVFBVUpLeWNHT29BQTlrZ3djNEl5bE0zYTZ4SVdYa0FzdFpFUXBs?=
 =?utf-8?B?dGx1UTJ2clVZVTVhb2JUTmUyaWhPRUVDQW9tdWxzMDlpMGhKYitkU3c5dm5R?=
 =?utf-8?B?R25IbUpuVDEyTDc3TjJldVpKc2JUZyt6VkQ4U3NnN2VBbXNhSEd1ODM0S0k0?=
 =?utf-8?B?M1VDZWk5d0dnZ0ZGZFo2MWNNOXp0N08xc3lmMEVnWWJXODRSZ0tTU3poZ0xE?=
 =?utf-8?B?cjZhUVBXb0dWaEo3OGFTVnlxRVFPY2JwWDRMRUw0ZCswaU0venFRandaYlRT?=
 =?utf-8?B?UWt6YnczWjhCUmZFdSs0ZGZPcVlubkVyaXdyL1dWWXludWR6Q1R1WmpDVlgx?=
 =?utf-8?B?aXJBdFcvM2N4MVF3WnZPbXdkdUJnRWNWMHJyYWVtaW4vMWpmL2t2SWw3ZHR4?=
 =?utf-8?B?QjR3d1FBcGg0NXVrMkJqb2ZhNTNmUE91K2xUWHR5eS9jaUMvWmVHOVVLNUkx?=
 =?utf-8?B?TDVZaDVKcDNxZzFibStUQ3J0bDkrV0NYU3BTaEdBUk4zeDJPR3lSTS9PcUJm?=
 =?utf-8?B?c25XWkdJN3V2eFdtK09pQU84UU9lOVdOYUJmSTBZRWZyRnB5TjNxUXpacVY5?=
 =?utf-8?B?YmdudTJDbHZnPT0=?=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: af257ed5-2390-45ff-a048-08da0cf9cd4b
X-MS-Exchange-CrossTenant-AuthSource: CO1PR10MB4705.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Mar 2022 18:20:26.2699
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: EzB3821zckmZH84RrOvqTb31JzOq0LZIa8QxukJJCYynZjZYLHhVINB5U6Ep6e3inbwzPLy721oKcKS7sMS0xw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR10MB1472
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10295 signatures=694973
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 suspectscore=0 spamscore=0
 mlxlogscore=999 phishscore=0 bulkscore=0 malwarescore=0 mlxscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2202240000
 definitions=main-2203230096
X-Proofpoint-GUID: cHNfDhnhVyfDf2aXqV-f6cAop3RQYmFr
X-Proofpoint-ORIG-GUID: cHNfDhnhVyfDf2aXqV-f6cAop3RQYmFr
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,
        T_SCC_BODY_TEXT_LINE 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 3/23/22 11:04 AM, Vincent Guittot wrote:
> On Tue, 22 Mar 2022 at 17:40, Tejun Heo <tj@kernel.org> wrote:
>>
>> Hello,
>>
>> On Tue, Mar 22, 2022 at 05:10:36PM +0100, Vincent Guittot wrote:
>>> latency_nice is quite similar to nice. The nice latency is used as an
>>> index to get a latency weight in the range [-1024:1024].  latency_nice
>>> is in the range [-20:19] and latency_prio shifts it in the range
>>> [0:40] . This index is then used to get the latency weight similar to
>>> how the nice prio is used to get a weight. That being said, the
>>> latency should probably reflect the latency_weight instead of the
>>> latency_prio in order to be aligned with the weight and weight.nice
>>> fields of cgroups.
>>>
>>> As described in patch 5 commit message, the weight is then used to
>>> compute a relative offset to check whether the waking task can preempt
>>> the current running task.
>>
>> So, what I'm trying to say is if it is actually a weight, just use weight
>> values instead of arbitrary mapped nice values. Nobody can tell how the
>> latency nice value of -2 compares against, say, 3. If you can define it
>> clearly in terms of weights (or something else clearly describable), it'd be
>> a lot better.
> 
> The current use is mapped to weight because weight makes sense when
> comparing vruntime but others might want to map the latency nice to
> something else in other places of the scheduler. Time but also others
> have mentioned the depth of the loop for looking an idle CPU

Reinforcing what Vincent said, about a year and half ago there were four different projects/ideas looking to do 
different but relatively compatible things based on the latency sensitivity of a task. We were looking for a number to 
describe this sensitivity, say like an integer. One of those projects wanted to do "bad for latency" power saving things 
so we then needed "good for latency", "neutral" and "potentially bad for latency". Call neutral 0, negative good and 
positive bad and there was a fair similarity to nice. Given that was an abstraction, we did recognize that beyond 
smaller numbers being more sensitive there really isn't much more you can say about the relationship between numbers. 
Certainly no guarantees of linearity.

-chrish