Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1997458imj; Sun, 17 Feb 2019 20:42:32 -0800 (PST) X-Google-Smtp-Source: AHgI3IZUHXxXogrT6s+OnCswudzY0LmTeR3Yu8VjiolVS3p+hIsKD6wQugwgx4vBuQt/1rMA8QCR X-Received: by 2002:a17:902:a514:: with SMTP id s20mr13064459plq.242.1550464952155; Sun, 17 Feb 2019 20:42:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550464952; cv=none; d=google.com; s=arc-20160816; b=eIxIbP1UQMDBhQhTj4ZK6w+67hGH6R/vCAN6tifiYxAlnaJMdeW3wHzpOgCNbgnhV/ ah+ynOGDkoE/UingDumltWVronrs4IykuNYbaleP4BAXDdSNRQOgDgM2SRWBN0dRLPTz YxAjZROf001MAppq/GkWzovZqk+DVp7DpzGIE7qSgc0qOysQOhL16dVsjd3yMB6lqL0P vrUp0QFmVbPSNOOj//0wu8JNTbxRZ4R0Vo2oNVo0/+yvscAHcbrXqHY2S61PEUW89XEg /oSbYPiHDF1Y6oUYZgSkLPGbH88OXpeY0pkbqfYGMniMwezTLeM4NA6swxWBPhB4dUji ZAcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:dlp-filter:cms-type :content-transfer-encoding:date:message-id:in-reply-to:cc:to:from :reply-to:subject:mime-version:dkim-signature:dkim-filter; bh=MYtaGIdr6501ly3aKVGw/1ZM7IAFGKVfdjfjCe6geJg=; b=bSkpkVo31eq85qZO6L0fvSoW8umcORs4ZJDxVgbGAzDV1bDoPBf7TLkB6CmD1G4Gar Ejmlh5FSqP6/2mGB0YRTNe9D/V6aHMjtvK/gvUcFh6ajPrSCIovWm5kq8VUf9CRoHewo Do0uhioGcZld35U/yrP+++DjjYOxVDfMMPc2ZgcwMqJB51Qi6rL4nSmKiMbonOCCFbDE zNRo8Fsou01eMGu6h6bhCUT8abhd34Qw42OBjXYiz560RLHAQPecZqynJrUCNlhpxHR7 keZ4iZVZ+Lnj8WdvJWjSqqSF+E25UNsGssHqOeW78bKGeAdt5qEi8N/Yjgi7RhIRDjOs CG+Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=WfV6D6oq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f11si12372040plo.254.2019.02.17.20.42.04; Sun, 17 Feb 2019 20:42:32 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@samsung.com header.s=mail20170921 header.b=WfV6D6oq; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=samsung.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727176AbfBREdS (ORCPT + 99 others); Sun, 17 Feb 2019 23:33:18 -0500 Received: from mailout1.samsung.com ([203.254.224.24]:52253 "EHLO mailout1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727003AbfBREdS (ORCPT ); Sun, 17 Feb 2019 23:33:18 -0500 Received: from epcas1p2.samsung.com (unknown [182.195.41.46]) by mailout1.samsung.com (KnoxPortal) with ESMTP id 20190218043314epoutp015df07cb9532eb16485ce7cfc08947d22~EWybf_oRK0911009110epoutp01i for ; Mon, 18 Feb 2019 04:33:14 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.samsung.com 20190218043314epoutp015df07cb9532eb16485ce7cfc08947d22~EWybf_oRK0911009110epoutp01i DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1550464394; bh=MYtaGIdr6501ly3aKVGw/1ZM7IAFGKVfdjfjCe6geJg=; h=Subject:Reply-To:From:To:CC:In-Reply-To:Date:References:From; b=WfV6D6oqVaQ14qUbypOBBOf7BX/09xs+c71PlHS0ULI/InLzN613d1sLrfJw1ytVr pt/kL+5izjzL2nt0lLtTekMVrt2A6X/lBubioviNQS2yQpDRmZXRhlUHXgyNkdX1nI lfHmdpasq7Yp+FkgLWMUbTJarpID1u1kZ9gbwkhQ= Received: from epsmges1p2.samsung.com (unknown [182.195.40.158]) by epcas1p4.samsung.com (KnoxPortal) with ESMTP id 20190218043311epcas1p413dcf023bff7d6d148e7f96c357ea32b~EWyZWd8SF0440904409epcas1p4D; Mon, 18 Feb 2019 04:33:11 +0000 (GMT) X-AuditID: b6c32a36-5c1ff7000000104d-c6-5c6a35871c10 Received: from epcas1p3.samsung.com ( [182.195.41.47]) by epsmges1p2.samsung.com (Symantec Messaging Gateway) with SMTP id 64.0B.04173.7853A6C5; Mon, 18 Feb 2019 13:33:11 +0900 (KST) Mime-Version: 1.0 Subject: RE: [PATCH v3 5/7] drivers: devfreq: add longer polling interval in idle Reply-To: myungjoo.ham@samsung.com From: MyungJoo Ham To: Lukasz Luba , "linux-kernel@vger.kernel.org" , "linux-pm@vger.kernel.org" CC: Bartlomiej Zolnierkiewicz , Chanwoo Choi , Kyungmin Park , Marek Szyprowski , Sylwester Nawrocki , "tkjos@google.com" , "joel@joelfernandes.org" , "chris.diamand@arm.com" , "mka@chromium.org" , "rostedt@goodmis.org" , "mingo@redhat.com" X-Priority: 3 X-Content-Kind-Code: NORMAL In-Reply-To: <1550010238-24002-6-git-send-email-l.luba@partner.samsung.com> X-Drm-Type: N,general X-Msg-Generator: Mail X-Msg-Type: PERSONAL X-Reply-Demand: N Message-ID: <20190218043311epcms1p33ccb2c312e871294025171d97bb87ac6@epcms1p3> Date: Mon, 18 Feb 2019 13:33:11 +0900 X-CMS-MailID: 20190218043311epcms1p33ccb2c312e871294025171d97bb87ac6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-CPGSPASS: Y X-CPGSPASS: Y CMS-TYPE: 101P X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrDJsWRmVeSWpSXmKPExsWy7bCmvm67aVaMwZZPhhYbZ6xntZj26TKL xctDmhbXvzxntVjWoGpxtukNu8WtBhmLy7vmsFl87j3CaLH2yF12i0sHFjBZfN7wmNFiX8cD JovDb9pZLd5PLnbg91gzbw2jx+yGiyweLftusXss2FTqsfDTV1aPg+/2MHm833eVzaNvyypG j8+b5AI4o7JtMlITU1KLFFLzkvNTMvPSbZW8g+Od403NDAx1DS0tzJUU8hJzU22VXHwCdN0y c4CuV1IoS8wpBQoFJBYXK+nb2RTll5akKmTkF5fYKqUWpOQUWBboFSfmFpfmpesl5+daGRoY GJkCFSZkZ8xc8YelYKlAxcN171gbGL/xdDFyckgImEisn3yIuYuRi0NIYAejxJ7Fa4AcDg5e AUGJvzuEQWqEBYIl9i2+yghiCwkoSTTc3McMEdeX6HiwDSzOJqArsXXDXRYQW0RgGaPE3LfW IDOZBb4zS3z6fp0RYhmvxIz2pywQtrTE9uVbweKcAt4Se/tuskPERSVurn4LZ78/Nh+qV0Si 9d5ZZghbUOLBz92MMHNmTPkPNbNa4lHPRbBnJARaGCVWzdzGBJHQlzgz9yQbiM0r4CtxtmEV WDOLgKpE27bJUINcJCa0rAEbxCwgL7H97RxwQDALaEqs36UPc3/Dxt/s6GxmAT6Jd197WGHi O+Y9gVqrJnFo9xKoehmJ09MXQt3vIXFk8jfGCYyKsxBBPQvJ4lkIixcwMq9iFEstKM5NTy02 LDBCjt1NjOCUrGW2g3HROZ9DjAIcjEo8vB/KMmOEWBPLiitzDzFKcDArifBaG2fFCPGmJFZW pRblxxeV5qQWH2I0Bfp/IrOUaHI+MF/klcQbmhoZGxtbmBiamRoaKonzrndwjhESSE8sSc1O TS1ILYLpY+LglGpg3KaW5eKtvNtELdyqh8263Heecnhi+7fXYfslvco+rDdbuXq/uqz75FQj za8vme2aNvnMY9XRjjvwfaH0tzclTjydeyo4WorCKuS+S9td0K7+Zfh03YKiKWZnHH6V8hVE 2W//9ueyg131rpgJjWcdy2Lju9/HKIbUuL616FAJ17er3qe/+4oSS3FGoqEWc1FxIgDZdLJY 3wMAAA== DLP-Filter: Pass X-CFilter-Loop: Reflected X-CMS-RootMailID: 20190212222436eucas1p21eebc80796406787a2ebf9a84ee5b868 References: <1550010238-24002-6-git-send-email-l.luba@partner.samsung.com> <1550010238-24002-1-git-send-email-l.luba@partner.samsung.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > This patch adds new mechanism for devfreq devices which changes polling > interval. The system should sleep longer when the devfreq device is almost > not used. The devfreq framework will not schedule the work too often. > This low-load state is recognised when the device is operating at the lowest > frequency and has low busy_time/total_time factor (< 30%). > When the frequency is different then min, the device is under normal polling > which is the value defined in driver's 'polling_ms'. > When the device is getting more pressure, the framework is able to catch it > based on 'load' in lowest frequency and will start polling more frequently. > The second scenario is when the governor recognised heavy load at minimum > frequency and increases the frequency. The devfreq framework will start > polling in shorter intervals. > The polling interval, when the device is not heavily, can also be changed > from userspace of defined by the driver's author. > > Signed-off-by: Lukasz Luba > --- > drivers/devfreq/devfreq.c | 151 +++++++++++++++++++++++++++--- > drivers/devfreq/governor.h | 3 +- > drivers/devfreq/governor_simpleondemand.c | 6 +- > 3 files changed, 145 insertions(+), 15 deletions(-) > There are some requirements that you need to consider: Is 30% really applicable to ALL devfreq devices? - What if some devices do not want such behaviors? - What if some devices want different values (change behavors)? - What if some manufactures want different default values? - What if some devices want to let the framework know that it's in idle? - What if some other kernel context, device (drivers), or userspace process want to notify that it's no more idling? As mentioned in the internal thread (tizen.org), I'm not convinced by the idea of assuming that a device can be considered "idling" if it has simply "low" utilization. You are going to deteriorate the UI response time of mobile devices significantly. Cheers, MyungJoo.