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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 C45BFC433E0 for ; Wed, 24 Jun 2020 13:44:14 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (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 8FB0C20857 for ; Wed, 24 Jun 2020 13:44:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="LfMik3Wg" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8FB0C20857 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Type: Content-Transfer-Encoding:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=bL6wObE/IZPzGcqS2W9YmkwjfFHlJ76zDMlFkHmX4ZM=; b=LfMik3Wgv14s9V4GyXDoYFtMJ iznyploFoh7frCTPaIu0ut7gPFtiEnTBrA4OPJhoS9eDqq6mQlS+vAeOmUlITHcPHebBOE7uIXEYQ LhhilxEVk2YmIjC+PvGUtBVw7g0lu5ZhF6cNDGCR8Dw7aahqUW7Zi5bHO0G5FQ9Nja8OmRCQmz2p/ JtkD3E8DIxbMfSaKEEjx9fimfMmHkBv9QaoY59ijMRYnveyywG5cpiYn4TsnrP8dVUNHt/ywmdUw2 JiqWMqbFi9pVSXZP4b9rpZrIm5YMxiSspzl/0q5vuWWskV8JAfQcCDe7rnfZALRJNdHF3wrZtY1F2 mzqIL1kQw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo5fN-00050F-O7; Wed, 24 Jun 2020 13:42:17 +0000 Received: from foss.arm.com ([217.140.110.172]) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo5fK-0004zI-Ce for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 13:42:15 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 4B1B81F1; Wed, 24 Jun 2020 06:42:13 -0700 (PDT) Received: from [10.37.12.79] (unknown [10.37.12.79]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 97BAD3F6CF; Wed, 24 Jun 2020 06:42:10 -0700 (PDT) Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4? To: Krzysztof Kozlowski References: <20200623164733.qbhua7b6cg2umafj@macmini.local> <20200623191129.GA4171@kozik-lap> <85f5a8c0-7d48-f2cd-3385-c56d662f2c88@arm.com> <828b0d63-4d01-48d6-5971-64855adebed2@samsung.com> <20200624120651.GA20813@pi3> <55772862-ff8f-1e1d-91ae-7b4d7c3be1b6@arm.com> <20200624131341.GA20905@pi3> From: Lukasz Luba Message-ID: Date: Wed, 24 Jun 2020 14:42:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <20200624131341.GA20905@pi3> Content-Language: en-US X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Willy Wolff , "linux-samsung-soc@vger.kernel.org" , linux-pm@vger.kernel.org, Kamil Konieczny , "linux-kernel@vger.kernel.org" , Chanwoo Choi , Kyungmin Park , Kukjin Kim , MyungJoo Ham , linux-arm-kernel@lists.infradead.org Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 6/24/20 2:13 PM, Krzysztof Kozlowski wrote: > On Wed, Jun 24, 2020 at 02:03:03PM +0100, Lukasz Luba wrote: >> >> >> On 6/24/20 1:06 PM, Krzysztof Kozlowski wrote: >>> My case was clearly showing wrong behavior. System was idle but not >>> sleeping - network working, SSH connection ongoing. Therefore at least >>> one CPU was not idle and could adjust the devfreq/DMC... but this did not >>> happen. The system stayed for like a minute in 633 MHz OPP. >>> >>> Not-waking up idle processors - ok... so why not using power efficient >>> workqueue? It is exactly for this purpose - wake up from time to time on >>> whatever CPU to do the necessary job. >> >> IIRC I've done this experiment, still keeping in devfreq: >> INIT_DEFERRABLE_WORK() >> just applying patch [1]. It uses a system_wq which should >> be the same as system_power_efficient_wq when >> CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set (our case). >> This wasn't solving the issue for the deferred work. That's >> why the patch 2/2 following patch 1/2 [1] was needed. >> >> The deferred work uses TIMER_DEFERRABLE in it's initialization >> and this is the problem. When the deferred work was queued on a CPU, >> next that CPU went idle, the work was not migrated to some other CPU. >> The former cpu is also not woken up according to the documentation [2]. > > Yes, you need either workqueue.power_efficient kernel param or CONFIG > option to actually enable it. But at least it could then work on any > CPU. > > Another solution is to use directly WQ_UNBOUND. > >> That's why Kamil's approach should be continue IMHO. It gives more >> control over important devices like: bus, dmc, gpu, which utilization >> does not strictly correspond to cpu utilization (which might be low or >> even 0 and cpu put into idle). >> >> I think Kamil was pointing out also some other issues not only dmc >> (buses probably), but I realized too late to help him. > > This should not be a configurable option. Why someone would prefer to > use one over another and decide about this during build or run time? > Instead it should be just *right* all the time. Always. I had the same opinion, as you can see in my explanation to those patches, but I failed. That's why I agree with Kamil's approach because had higher chance to get into mainline and fix at least some of the use cases. > > Argument that we want to save power so we will not wake up any CPU is > ridiculous if because of this system stays in high-power mode. > > If system is idle and memory going to be idle, someone should be woken > up to save more power and slow down memory controller. > > If system is idle but memory going to be busy, the currently busy CPU > (which performs some memory-intensive job) could do the job and ramp up > the devfreq performance. I agree. I think this devfreq mechanism was designed in the times where there was/were 1 or 2 CPUs in the system. After a while we got ~8 and not all of them are used. This scenario was probably not experimented widely on mainline platforms. That is a good material for improvements, for someone who has time and power. Regards, Lukasz > > Best regards, > Krzysztof > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel