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 X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 47CE4C433E0 for ; Tue, 4 Aug 2020 07:48:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4154D22B40 for ; Tue, 4 Aug 2020 07:48:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596527284; bh=pS1WPK1i6yro2DLNjCjUZpZoNv0ByMmOkSSvxn+6F1o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=FmKxKdUMwUsPHeO619soivhzw4K/VE7NY3owwXLkfIcjzq/BtsUFQIAuC8x7qpz7j /U5isKi3tq3Co6vK0EjOQ2iUgeuaszhBtcBzJhiuAUAsBdZPql38Fo2Ct7mtIVfgJV WzFc8191Z4XSdNfglLmYS6CVOMPOJQpAVrJpXOeE= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726547AbgHDHsD (ORCPT ); Tue, 4 Aug 2020 03:48:03 -0400 Received: from mail.kernel.org ([198.145.29.99]:54016 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726036AbgHDHsC (ORCPT ); Tue, 4 Aug 2020 03:48:02 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9FB172086A; Tue, 4 Aug 2020 07:48:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596527281; bh=pS1WPK1i6yro2DLNjCjUZpZoNv0ByMmOkSSvxn+6F1o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QR3Hg6B44CqSd0jBaGgC7l8EdzRxprSXs/tZkN+GLYXwGA0QXuHoiQay1oVd7+7iT Qgog646pCVwry06e6Eb2tN1DdP9YaEKOTWpKbMGJiWdIrXaTABImI5q4i9tSZK1hUj LGHwlw5aKnCqbsvuj9AeANPuw29rbzUcZwlOm7Rs= Date: Tue, 4 Aug 2020 09:47:41 +0200 From: Greg KH To: Dongdong Yang Cc: Viresh Kumar , rjw@rjwysocki.net, mingo@redhat.com, peterz@infradead.org, juri.lelli@redhat.com, Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Benjamin Segall , mgorman@suse.de, linux-kernel@vger.kernel.org, devel@driverdev.osuosl.org, linux-pm@vger.kernel.org, yangdongdong@xiaomi.com, tanggeliang@xiaomi.com, taojun@xiaomi.com, huangqiwu@xiaomi.com, rocking@linux.alibaba.com, fengwei@xiaomi.com, zhangguoquan@xiaomi.com, gulinghua@xiaomi.com, duhui@xiaomi.com Subject: Re: [PATCH v3] Provide USF for the portable equipment. Message-ID: <20200804074741.GA1761483@kroah.com> References: <20200804054728.ojudxu5fmd54lar5@vireshk-mac-ubuntu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Aug 04, 2020 at 03:34:25PM +0800, Dongdong Yang wrote: > Appreciate Viresh for your help. I thought Peter's NAK was only for the > initial version. I am going to upload the verified version 4. Could you > please kindly help to further review? > > 1. Motivation > ============= > > The power consumption and UI response are more cared for by the portable > equipment users. That's not true, everyone cares about this. > USF(User Sensitive Feedback factor) auxiliary cpufreq > governor > is providing more utils adjustment settings to the high level by scenario > identification. Odd line-wrapping :( And what do you mean by "more utils adjustment settings to the high level by scenario identification"? I can not parse that at all. > 2. Introduction > =============== > > The USF auxiliary scheduling is based on FrameBuffer and schdeutil cpufreq > governor to adjust utils by the identificated scenario from User Space. What is "adjust utils"? And why is "User Space" in caps? > It is for portable equipment which "screen off" status stands for no request > from the user, however, the kernel is still expected to notify the user for > UI in > time on modem, network or powerkey events occur. In order to save power, the > sysfs inode nonux is provided to set the utils down level on userspace > tasks. Having custom sysfs apis is almost never a good idea. Do other cpufreq governers do this? > In addition, the portable equipment users usually heavily interact with > devices > by touch, and other peripherals. On "screen on" status, The boost preemptive > counts are marking the load requirement urgent, vice versa. USF provides up > and > down sysfs inodes to adjust utils according to such feedback factor and the > level setting from the user space identified scenario. > > adjust_task_pred_set is as the switch to enable or disable the adjustment. > If no USF sysfs inodes is set and no screen on or off event be received, > adjust_task_pred_demand shall not be executed. > > 3. System wide settings > ======================= > > sched_usf_non_ux_r: > The ratio of utils is cut down on screen off. The default value is > 0, The line-wrapping makes it almost impossible to read here, can you fix that up? > which no util be adjusted on sugov calculating utils to select "sugov"? > cpufreq. > Its range is [-100 , 0]. If its value falls into [-50, 0), the half > of > utils, which calculates cpufreq, shall be cut down. If its value > falls > into [-100, -50), only a quarter of utils be left to continue to > calculates cpufreq. > It is expected to be set [-100, 0) once enter into the identificated > scenario, such as listen to music on screen off, and recover to 0 on > out of the scenario, such as screen on. sysfs files are "one value per file", please do not parse such complex things in the kernel. > > sched_usf_up_l0_r: > The ratio of utils is boosted up on screen on. The default value is > 0, > which no util be adjusted on sugov calculates utils to select > cpufreq. > Its range is [0 , 100]. If its value falls into (0, 50], a quarter > of > extra utils, which calculates cpufreq, shall be added. If its value > falls into (50, 100], the half of extra utils be added to continue > to > calculates cpufreq. > It is expected to be set (0, 100] once enter into the identificated > scenario, such as browsing videolet on screen on, and recover to 0 > on > out of the scenario, such as screen off or videolet into background. > > sched_usf_down_r: > The ratio of utils is cut down on screen on. The default value is 0, > which no util be adjusted on sugov calculating utils to select > cpufreq. > Its range is [-100 , 0]. If its value falls into [-50, 0), the half > of > utils, which calculates cpufreq, shall be cut down. If its value > falls > into [-100, -50), only a quarter of utils be left to continue to > calculates cpufreq. > It is expected to be set [-100, 0) once enter into the identificated > scenario, such as browsing videolet on screen on, and recover to 0 > on > out of the scenario, such as screen off or vidolet into background. Why can't all of these work automatically? Why do you need userspace interaction here? thanks, greg k-h 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 X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id ECCAFC433E1 for ; Tue, 4 Aug 2020 07:48:05 +0000 (UTC) Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id E3D6422B40 for ; Tue, 4 Aug 2020 07:48:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="QR3Hg6B4" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E3D6422B40 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linuxfoundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=driverdev-devel-bounces@linuxdriverproject.org Received: from localhost (localhost [127.0.0.1]) by hemlock.osuosl.org (Postfix) with ESMTP id 6477C8733F; Tue, 4 Aug 2020 07:48:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from hemlock.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mVGSI7t40WJy; Tue, 4 Aug 2020 07:48:03 +0000 (UTC) Received: from ash.osuosl.org (ash.osuosl.org [140.211.166.34]) by hemlock.osuosl.org (Postfix) with ESMTP id A210587118; Tue, 4 Aug 2020 07:48:03 +0000 (UTC) Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by ash.osuosl.org (Postfix) with ESMTP id 2504C1BF2A7 for ; Tue, 4 Aug 2020 07:48:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by fraxinus.osuosl.org (Postfix) with ESMTP id 1E06885087 for ; Tue, 4 Aug 2020 07:48:02 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from fraxinus.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ks9VMbnRNAzm for ; Tue, 4 Aug 2020 07:48:01 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by fraxinus.osuosl.org (Postfix) with ESMTPS id 6846584DFD for ; Tue, 4 Aug 2020 07:48:01 +0000 (UTC) Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 9FB172086A; Tue, 4 Aug 2020 07:48:00 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1596527281; bh=pS1WPK1i6yro2DLNjCjUZpZoNv0ByMmOkSSvxn+6F1o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=QR3Hg6B44CqSd0jBaGgC7l8EdzRxprSXs/tZkN+GLYXwGA0QXuHoiQay1oVd7+7iT Qgog646pCVwry06e6Eb2tN1DdP9YaEKOTWpKbMGJiWdIrXaTABImI5q4i9tSZK1hUj LGHwlw5aKnCqbsvuj9AeANPuw29rbzUcZwlOm7Rs= Date: Tue, 4 Aug 2020 09:47:41 +0200 From: Greg KH To: Dongdong Yang Subject: Re: [PATCH v3] Provide USF for the portable equipment. Message-ID: <20200804074741.GA1761483@kroah.com> References: <20200804054728.ojudxu5fmd54lar5@vireshk-mac-ubuntu> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: driverdev-devel@linuxdriverproject.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux Driver Project Developer List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: juri.lelli@redhat.com, peterz@infradead.org, Viresh Kumar , Benjamin Segall , gulinghua@xiaomi.com, duhui@xiaomi.com, rocking@linux.alibaba.com, devel@driverdev.osuosl.org, Vincent Guittot , tanggeliang@xiaomi.com, mingo@redhat.com, yangdongdong@xiaomi.com, mgorman@suse.de, linux-pm@vger.kernel.org, Steven Rostedt , fengwei@xiaomi.com, taojun@xiaomi.com, Dietmar Eggemann , huangqiwu@xiaomi.com, rjw@rjwysocki.net, linux-kernel@vger.kernel.org, zhangguoquan@xiaomi.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: driverdev-devel-bounces@linuxdriverproject.org Sender: "devel" A: http://en.wikipedia.org/wiki/Top_post Q: Were do I find info about this thing called top-posting? A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Tue, Aug 04, 2020 at 03:34:25PM +0800, Dongdong Yang wrote: > Appreciate Viresh for your help. I thought Peter's NAK was only for the > initial version. I am going to upload the verified version 4. Could you > please kindly help to further review? > > 1. Motivation > ============= > > The power consumption and UI response are more cared for by the portable > equipment users. That's not true, everyone cares about this. > USF(User Sensitive Feedback factor) auxiliary cpufreq > governor > is providing more utils adjustment settings to the high level by scenario > identification. Odd line-wrapping :( And what do you mean by "more utils adjustment settings to the high level by scenario identification"? I can not parse that at all. > 2. Introduction > =============== > > The USF auxiliary scheduling is based on FrameBuffer and schdeutil cpufreq > governor to adjust utils by the identificated scenario from User Space. What is "adjust utils"? And why is "User Space" in caps? > It is for portable equipment which "screen off" status stands for no request > from the user, however, the kernel is still expected to notify the user for > UI in > time on modem, network or powerkey events occur. In order to save power, the > sysfs inode nonux is provided to set the utils down level on userspace > tasks. Having custom sysfs apis is almost never a good idea. Do other cpufreq governers do this? > In addition, the portable equipment users usually heavily interact with > devices > by touch, and other peripherals. On "screen on" status, The boost preemptive > counts are marking the load requirement urgent, vice versa. USF provides up > and > down sysfs inodes to adjust utils according to such feedback factor and the > level setting from the user space identified scenario. > > adjust_task_pred_set is as the switch to enable or disable the adjustment. > If no USF sysfs inodes is set and no screen on or off event be received, > adjust_task_pred_demand shall not be executed. > > 3. System wide settings > ======================= > > sched_usf_non_ux_r: > The ratio of utils is cut down on screen off. The default value is > 0, The line-wrapping makes it almost impossible to read here, can you fix that up? > which no util be adjusted on sugov calculating utils to select "sugov"? > cpufreq. > Its range is [-100 , 0]. If its value falls into [-50, 0), the half > of > utils, which calculates cpufreq, shall be cut down. If its value > falls > into [-100, -50), only a quarter of utils be left to continue to > calculates cpufreq. > It is expected to be set [-100, 0) once enter into the identificated > scenario, such as listen to music on screen off, and recover to 0 on > out of the scenario, such as screen on. sysfs files are "one value per file", please do not parse such complex things in the kernel. > > sched_usf_up_l0_r: > The ratio of utils is boosted up on screen on. The default value is > 0, > which no util be adjusted on sugov calculates utils to select > cpufreq. > Its range is [0 , 100]. If its value falls into (0, 50], a quarter > of > extra utils, which calculates cpufreq, shall be added. If its value > falls into (50, 100], the half of extra utils be added to continue > to > calculates cpufreq. > It is expected to be set (0, 100] once enter into the identificated > scenario, such as browsing videolet on screen on, and recover to 0 > on > out of the scenario, such as screen off or videolet into background. > > sched_usf_down_r: > The ratio of utils is cut down on screen on. The default value is 0, > which no util be adjusted on sugov calculating utils to select > cpufreq. > Its range is [-100 , 0]. If its value falls into [-50, 0), the half > of > utils, which calculates cpufreq, shall be cut down. If its value > falls > into [-100, -50), only a quarter of utils be left to continue to > calculates cpufreq. > It is expected to be set [-100, 0) once enter into the identificated > scenario, such as browsing videolet on screen on, and recover to 0 > on > out of the scenario, such as screen off or vidolet into background. Why can't all of these work automatically? Why do you need userspace interaction here? thanks, greg k-h _______________________________________________ devel mailing list devel@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel