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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A41CCC4332F for ; Sat, 17 Dec 2022 22:03:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=iRdLc7IKbtxiApd4gJZBXpRQfruMM1SEBuQxY+Gr7mQ=; b=ELCb5BAhN2rXLT Snz/k2qYZnEXESA1RcUwlacOVUQx/nxN1HMXlvY7Rydemjq8nBTg/6ZmIrL4TKPfsY66skt/Iu3eq Jzw25HuksALQVbjR7J1T+i0dzLC3ZWLkXRgeUtoXEAo5/meAqjzjdHuINGX482mEn0l/9tLt0+/k4 EwjwMj5k7P+Lv2vu0mnRz2Xmn7QzYEs5Xqlgast2bjPbUUjMA323OdMV22VpK2KhatPcINQpD6lUx b0SGkrLjz+tGVVPlx9I9a0LZHwgGJ9nr/NJzg73sAnTesnx12Ea0g35XOP3JlbXXxXRf1MAs6hNKb e5PGu9Xf+gigj0Olsz4Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1p6fFU-00DFK4-T1; Sat, 17 Dec 2022 22:01:41 +0000 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1p6fFR-00DFJ4-Mp for linux-arm-kernel@lists.infradead.org; Sat, 17 Dec 2022 22:01:39 +0000 Received: by mail-wm1-x333.google.com with SMTP id p13-20020a05600c468d00b003cf8859ed1bso4046185wmo.1 for ; Sat, 17 Dec 2022 14:01:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=layalina-io.20210112.gappssmtp.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hOSkvzS5rw9RqReI9DDRUaJAR+FURiQ8Kin2htoeGpw=; b=NNR2VsX7aR4bcPxEa4k1u9Clg3hy+/LnwwxOFJ2Z4F6ZO9LNftOkW9gHnWEfHhVilB NIng3eJ5DCU7l9c5VkOdEguqWz60y2g6S2kEqLTVje4M2uTR6aDaepL973vTvpsMPEsQ 7TpRM9T2HD71mIqkruO1vmfE2JMAJ1fNve6nJ8kYZuxhlWexEuuxRksJquPNLn2e2SrW VGaquzXROZiNfKnBn9qnwR9tPIe7BPkuq4/mFgw9GBICO1PznyVrJPUG0swlGfhODZUD zp8iB41Nvv8LMLJtbLJj3iHNupJD+MlgWKObZQjGf8a054QB5EZrP6Y8Sk2BPM6C3NO6 5iPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hOSkvzS5rw9RqReI9DDRUaJAR+FURiQ8Kin2htoeGpw=; b=gh/hjhQ+pKxRV0/64SY8maDbcqEFnF8dqyJyGsZV5i2sG2EUndDSvTyf4WdNjk+VMO wL71BfhK0C09c95XkdgQbYClUvGKwRmpUheoyc2FBJynlWcvcEDgIO6CHVezT6vdtIhy +tkcrZhB515Si7NwPe5wdDeOkEAG+o2drkYL4huy+M8VdYaSKeiVR5vB+uKfJLQShsg2 EeFOkdaebrKQktenOmW515FT88E2SuTflM4gnXuSjB0D8DYgT3JN6vcCvnPaXwoQVzoo y8bo3W5duBbPlUMBscMypaNalBVC3wBULDFVI+gqAsCTXajHmBjdqe2idt+LkJxMWyfa kl2g== X-Gm-Message-State: ANoB5pnUBoq1oOcbo3xidYXdyCSV5x9I7Az5rnASyUhwI1BrmupwItBd WbcZhPGpOILw0fZWe6WoWxBELw== X-Google-Smtp-Source: AA0mqf5A3p2VTGjx8f3Y09Xd8A9AhGsa3AUBDhVMfoM707A+zXdIeQZ+CFn9Unh7HzIGid2zUwW8Ew== X-Received: by 2002:a05:600c:a0f:b0:3d0:8a0e:3910 with SMTP id z15-20020a05600c0a0f00b003d08a0e3910mr28797701wmp.34.1671314495353; Sat, 17 Dec 2022 14:01:35 -0800 (PST) Received: from airbuntu (host86-130-134-87.range86-130.btcentralplus.com. [86.130.134.87]) by smtp.gmail.com with ESMTPSA id q9-20020a7bce89000000b003d1e34bcbb2sm6826036wmj.13.2022.12.17.14.01.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 17 Dec 2022 14:01:34 -0800 (PST) Date: Sat, 17 Dec 2022 22:01:33 +0000 From: Qais Yousef To: Bagas Sanjaya Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Dietmar Eggemann , Jonathan Corbet , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Linux ARM , Lukasz Luba , Xuewen Yan , Wei Wang , Jonathan JMChen , Hank , Paul Bone , Russell King , Linus Walleij , Catalin Marinas Subject: Re: [PATCH v3] Documentation: sched: Document util clamp feature Message-ID: <20221217220133.p5wh7drpvkmkups2@airbuntu> References: <20221216235716.201923-1-qyousef@layalina.io> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20221217_140137_871738_E685B62C X-CRM114-Status: GOOD ( 25.82 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 12/17/22 16:53, Bagas Sanjaya wrote: > On Fri, Dec 16, 2022 at 11:57:16PM +0000, Qais Yousef wrote: > > +Another example is in Android where tasks are classified as background, > > +foreground, top-app, etc. Util clamp can be used to constrain how much > > +resources background tasks are consuming by capping the performance point they > > +can run at. This constraint helps reserve resources for important tasks, like > > +the ones belonging to the currently active app (top-app group). Beside this > > +helps in limiting how much power they consume. This can be more obvious in > > +heterogeneous systems (e.g. Arm big.LITTLE); the constraint will help bias the > > +background tasks to stay on the little cores which will ensure that: > > + > > + 1. The big cores are free to run top-app tasks immediately. top-app > > + tasks are the tasks the user is currently interacting with, hence > > + the most important tasks in the system. > > + 2. They don't run on a power hungry core and drain battery even if they > > + are CPU intensive tasks. > > + > > +.. note:: > > + **little cores**: > > + CPUs with capacity < 1024 > > + > > + **big cores**: > > + CPUs with capacity = 1024 > > Processing capacity (CPU frequency) in MHz? This is the first time I This is a scheduler abstraction value from 0-1024. Biggest CPU always has a capacity of 1024. On SMP all cpus appear as 1024 CPUs. > hear Arm big.LITTLE architecture. CC'ing several Arm folks and > linux-arm-kernel list for I'm unsure on this. This has my Arm SoB :-) This was added based on Lukasz comments. Both Lukasz and Dietmar were my colleagues at Arm and are on CC. I don't think it was necessary to expand the recipients list. But probably more is better though all the scheduler people are covered. This has nothing to do with Arm but it's the prime example of heterogeneous systems. > > > + > > +By making these uclamp performance requests, or rather hints, user space can > > +ensure system resources are used optimally to deliver the best possible user > > +experience. > > + > > +Another use case is to help with **overcoming the ramp up latency inherit in > > +how scheduler utilization signal is calculated**. > > IMO the bold text isn't needed (why did you highlight the phrase above)? > > > +When task @p is running, **the scheduler should try its best to ensure it > > +starts at 40% performance level**. If the task runs for a long enough time so > > +that its actual utilization goes above 80%, the utilization, or performance > > +level, will be capped. > > Same here. > > > +**Generally it is advised to perceive the input as performance level or point > > +which will imply both task placement and frequency selection**. > > Same here too. All of these were added based on Lukasz review comments. He thought they're important pieces and should be highlighted, I opted to do that by making them bold text. Thanks! -- Qais Yousef _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel