Received: by 2002:a05:6a10:1287:0:0:0:0 with SMTP id d7csp1817316pxv; Fri, 23 Jul 2021 19:06:16 -0700 (PDT) X-Google-Smtp-Source: ABdhPJygzjp/RsaMZu79hAOKg3aYXX1CXqSxIiHQQGZ3MLwKQfYZYDPZQy0eeNHH221ZJi0u1fKm X-Received: by 2002:a17:906:c302:: with SMTP id s2mr7280728ejz.151.1627092375935; Fri, 23 Jul 2021 19:06:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627092375; cv=none; d=google.com; s=arc-20160816; b=mAuVvsw92rOhe61oAOC9bGlnKZbtWSS1sVhWB+DV5k2bmAGtGAhH+sjcnTCOXKQK2X ZOicWEcpNvfCqxY6WLLNGVWSvObvvJswlO+EK8KLvQ0RJhRQKd5rzG3tppWUQ7fssU96 05bCHKCiYgDhzqSTZkWL39JrsMonJ9kuqRKYdZSYTLkQDBb3SN69OGiK2lF9od6hFOBC iYvr3WRqKzktMasjiVol0q80yiFkGpuEERQFyvpPy9d+r0u6lO7ufrjYXEImOud/uGVT IbZzSYQcp3zg5VaZr3L0ynvg9jb1HHgxdbsZbtdhX5iCmhiJYaLvPLE87T7Ub9h7zSuI MO0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=JRhtYPLybNJwcgnJP8HfuZI7PNUTaAlWJppJtdWcRvc=; b=I9kWQLR42OwzEBvvoxFf/fLbUll33F4yL4kGdP7IP6Yti4gYP9r+rlzXhLeRTON+ft PycaHXqal1mHXWxfeXPDPg1jQ2MNYDoyvrse8QGOsb9tte4VSKBwAuZ4JSPP0Z7+EPih dGQc3ugLmEVMVN0xUIPrbd7PMFyJg3/GJoanwSbxB6EqyN6QoduwBafDS92SSmx6sO9V nUI5AE/b8KS3HsXnt3Hy12LZBUC5AKj3uUSm3jy7LPtSnnWTmiRAcWogNS/Dlnb3MetB U8GXv3XO8iweVkpR5rcZ3yQeh/Fladbm+9ZFgFg8j6M10vSKyvmDHyqNNtvYBq7P1ZxL Ifwg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=GXfg42Vl; 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 d12si33538000ejj.50.2021.07.23.19.05.50; Fri, 23 Jul 2021 19:06:15 -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=GXfg42Vl; 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 S233618AbhGXBXe (ORCPT + 99 others); Fri, 23 Jul 2021 21:23:34 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50650 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233366AbhGXBXd (ORCPT ); Fri, 23 Jul 2021 21:23:33 -0400 Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 3FE7DC061575; Fri, 23 Jul 2021 19:04:05 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id n6so3844107ljp.9; Fri, 23 Jul 2021 19:04:05 -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:content-transfer-encoding; bh=JRhtYPLybNJwcgnJP8HfuZI7PNUTaAlWJppJtdWcRvc=; b=GXfg42VlQV6TSuE7SMG54+5e4Wm5/bUTC+SZPv62iZGgAu+lxXZXoEz7OYyUxtwdmb uCBs3NOZZs5fitM9rDVyp52LEL+hPzPpn0+lwyqEc6FPaVw2ZOygQN/PkNJAfvB6D796 rOAh9m87t4Zu5p/KOd+bX8yt3NpfxG+cPAi7VleUwktj3JOPyUxEWR7NOah7hvAN9tgO 6AopFYdIr4/fKUzyXW+XEoiVt6EyGP+hQssGZ0jli410iYydcd8KnAJ9CgsYP0Q7a4CM XoD119IMcx5leIRGjJqa1LYqqtDFKJIwWHToLfG8LiJ2xF1qUvGPLHwbEilER9Yxo5fQ j+2w== 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:content-transfer-encoding; bh=JRhtYPLybNJwcgnJP8HfuZI7PNUTaAlWJppJtdWcRvc=; b=MOdxcuu+jA4+psUoFdCI2SsHYPJX447mk/kY5BtC8XQdvYyAsUYf42S4DjzXWq3LUx xVFap+gVrRViY+3uzCG9qk+CEuxcRQDq126LpO3zL62t/6j+3a7onjOYuXy+tNL9MWRT ULYGGGj1XChanX9renpbhXB7bGr/u1zjMI24sLothw15PJeCDA+JNcB8TvV3YCpqFu8S pBwONXfhyT9jmwsBDJVwMQTuPfLQz69/mLYIFnuVhNHGrU5fsF/i0YTYKNEtSFyiNbWU B/D6C8yPagbtVH87ZV50kCGwx9aIVqdetcZzSJX0koGpt5ESBsOifsEuc3ygQhUMUb4p 5qFw== X-Gm-Message-State: AOAM531yi4Il/H/cG4Kop1EQx++jC8zQxBOka4pVdXno6dVdWdPZ9GOr FYe/ZdirhrdR2aW69OiGn3YtnHGM7L8nYcHC8Ww= X-Received: by 2002:a2e:b0cb:: with SMTP id g11mr4960465ljl.227.1627092243482; Fri, 23 Jul 2021 19:04:03 -0700 (PDT) MIME-Version: 1.0 References: <20210721075751.542-1-xuewen.yan94@gmail.com> In-Reply-To: From: Xuewen Yan Date: Sat, 24 Jul 2021 10:03:49 +0800 Message-ID: Subject: Re: [PATCH] sched/uclamp: Introduce a method to transform UCLAMP_MIN into BOOST To: Dietmar Eggemann Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Benjamin Segall , Mel Gorman , Daniel Bristot de Oliveira , mcgrof@kernel.org, Kees Cook , Iurii Zaikin , Paul Turner , Qais Yousef , Quentin Perret , linux-kernel , linux-fsdevel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 23, 2021 at 11:19 PM Dietmar Eggemann wrote: > > On 21/07/2021 09:57, Xuewen Yan wrote: > > From: Xuewen Yan > > > > The uclamp can clamp the util within uclamp_min and uclamp_max, > > it is benifit to some tasks with small util, but for those tasks > > with middle util, it is useless. > > > > To speed up those tasks, convert UCLAMP_MIN to BOOST, > > the BOOST as schedtune does: > > Maybe it's important to note here that schedtune is the `out-of-tree` > predecessor of uclamp used in some Android versions. Yes, and the patch is indeed used on Android which kernel version is 5.4+. Because the kernel used in Android do not have the schedtune, and the uclamp can not boost all the util, and this is the reason for the design of the patch. > > > boot =3D uclamp_min / SCHED_CAPACITY_SCALE; > > margin =3D boost * (uclamp_max - util) > > boost_util =3D util + margin; > > This is essentially the functionality from schedtune_margin() in > Android, right? YES! > > So in your implementation, the margin (i.e. what is added to the task > util) not only depends on uclamp_min, but also on `uclamp_max`? Yes, because we do not want to convert completely the uclamp to schedtune, we also want user can limit some tasks, so the UCLAMP_MAX's meaning has not been changed=EF=BC=8C meanwhile, the UCLAMP_MAX also can affect the margin. > > > Scenario: > > if the task_util =3D 200, {uclamp_min, uclamp_max} =3D {100, 1024} > > > > without patch: > > clamp_util =3D 200; > > > > with patch: > > clamp_util =3D 200 + (100 / 1024) * (1024 - 200) =3D 280; > > The same could be achieved by using {uclamp_min, uclamp_max} =3D {280, 10= 24}? Yes, for per-task, that is no problem, but for per-cgroup, most times, we can not always only put the special task into the cgroup. For example, in Android , there is a cgroup named "top-app", often all the threads of a app would be put into it. But, not all threads of this app need to be boosted, if we set the uclamp_min too big, the all the small task would be clamped to uclamp_min, the power consumption would be increased, howerever, if setting the uclamp_min smaller, the performance may be increased. Such as: a task's util is 50, {uclamp_min, uclamp_max} =3D {100, 1024} the boost_util =3D 50 + (100 / 1024) * (1024 - 50) =3D 145; but if we set {uclamp_min, uclamp_max} =3D {280, 1024}, without patch: the clamp_util =3D 280. > > Uclamp_min is meant to be the final `boost( =3D util + margin)` > information. You just have to set it appropriately to the task (via > per-task and/or per-cgroup interface). As said above, it is difficult to set the per-cgroup's uclamp_min for all tasks in Android sometimes. > > Uclamp_min is for `boosting`, Uclamp max is for `capping` CPU frequency. Yes! > Thanks! xuewen