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=-1.0 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 D0F99C433DF for ; Wed, 24 Jun 2020 13:15:37 +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 A006A20720 for ; Wed, 24 Jun 2020 13:15:37 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="P5DRyAX+" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A006A20720 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org 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-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References:Message-ID: Subject: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=O313ZxftS7ylThkOs01t9Q36RFz/OCeP6FOfHwJTUrw=; b=P5DRyAX+SzoIaGWsJwX0Ugk93 gUDg4vffmOKC+vkooiX7/gThHOuRtYMPISCyfPqsjmOdWKbMopmWdqrDsgNjIoMw4sE4ghR3cWCuy TcoODUFSkwTZXaGaKwQNVwOIykYKr1WB04TZHkMBqpe3PHsYhltDfy8ZFpB0h5a36uB/o18ozzu+s vptUh6uuGK0kSUtGEK8aqqz4a6Y35J/5yFBj4O51614U/zvuwL3A8QZgmCCWll6DUogRVRCS8/Xli rka8R4OTuE37WFVA0LK0z64MzGaHX/rK7HpUnDpVAavwG152xR5zezHfqN/QqMOZaHH6KkO1KGTcI xhwybtdxA==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo5Do-0006Y0-EA; Wed, 24 Jun 2020 13:13:48 +0000 Received: from mail-ej1-f67.google.com ([209.85.218.67]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jo5Dl-0006WS-9x for linux-arm-kernel@lists.infradead.org; Wed, 24 Jun 2020 13:13:46 +0000 Received: by mail-ej1-f67.google.com with SMTP id ga4so2370876ejb.11 for ; Wed, 24 Jun 2020 06:13:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=BDyIAIkz+outt0wjRZXFGz7XkAFPA/tTfRPsaqbeBic=; b=d2MQ7oKhdjFSD77GC76qsNnVuggrKbFKA095iMm+9L0+VVxbSoK/NkJzSk80GkqPwb dbeiiZ6TV7opAiFYQJFT+cnn27gC+6FwIGsU2TUIo3qEibFSaTuDzliAdjNmQTLNcB48 lFdqCFLSD48qCcH50nfzKwICKsspPZrvoajlumv7nb3iHnZgEyAjnY7526VCTJ+OUJir flZ6AU2ZeI6N1ZJhVmCz8FKQEjvSm+oiubFy55iaJE37UWF+9s+/Pu7Zd0yzF/IpUEkT 4z21IMaPnqyyKTeDHo4phpiiFpxYMeAOtvNQlqpXdkMtyueymu7NM1d8/eel3y+mssTO Vd6g== X-Gm-Message-State: AOAM533+tPpg3KeByM9a1jW84d4pnOR543pyust4IyTol7/IZAjCtzft a3KvOzCE+6GYauamAY+vZ4I= X-Google-Smtp-Source: ABdhPJzzPyKDomrh74GPMsORKH0aJpm0N4ocflgfVK159jT1jxEJ+S6d46lyTXjIsXY0GWgw/Bnkjg== X-Received: by 2002:a17:906:ca56:: with SMTP id jx22mr11630669ejb.494.1593004424202; Wed, 24 Jun 2020 06:13:44 -0700 (PDT) Received: from pi3 ([194.230.155.235]) by smtp.googlemail.com with ESMTPSA id ss4sm15386027ejb.63.2020.06.24.06.13.42 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 24 Jun 2020 06:13:43 -0700 (PDT) Date: Wed, 24 Jun 2020 15:13:41 +0200 From: Krzysztof Kozlowski To: Lukasz Luba Subject: Re: brocken devfreq simple_ondemand for Odroid XU3/4? Message-ID: <20200624131341.GA20905@pi3> 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> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <55772862-ff8f-1e1d-91ae-7b4d7c3be1b6@arm.com> 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-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 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. 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. Best regards, Krzysztof _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel