Received: by 10.223.185.116 with SMTP id b49csp3337244wrg; Sun, 25 Feb 2018 20:31:22 -0800 (PST) X-Google-Smtp-Source: AH8x227nOQXCJB8qpkwPteHMmV7C+oLVekV2j5571J8k0nEKRpvvDDS3aj4Y2GVP+HexPG8eHgoU X-Received: by 10.98.153.86 with SMTP id d83mr8224409pfe.46.1519619482702; Sun, 25 Feb 2018 20:31:22 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1519619482; cv=none; d=google.com; s=arc-20160816; b=0xH7DZHj/MEPit+eX6BPFFe+O8iDlcWiIi0OfGeRQX38keoxhi0tBhbfCdh6GTGgn1 Sb41AFb0gxN5wExrh7zekQdsKF1AtaW+K7ok1IvR57F7EEMK4Yvs4ayxgwXIaT57aGJL uM+MnW7/wZCNDxS/yrmTN1XP3O0QsGJYFtW98Br8J17KDQuJO8y82L1J/0u5mrf8GkVT oxZy0sx1vOzc8MtrYRNs9J50OECM8IOYFUrFW2oKklAl3hocHgFkBmhcoyNtoy1fBFts tt5mTkrPvPK4aatHbfdODxVzccj489+PyhXTdhYE34Tn5oW8CRuJ4MJMqtGenAf1g1P0 Wpig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=NohqUlE/+V+aR3ocr70lW71L2G3m6M7gmVL7/ltFtSM=; b=bxNaCEB2uanPLozXo4fDxo4DTghMsf2L+6grWZ5n5kbZPvw77dJj1gjZ/vVWs98UL5 eq+pf+pBjAEGsjViQHmj3vBNdYT/dwQ7lazTsaQfv2C/HbMYVP1vOw+0oZLHxeOWD/FY nxgvNWZgZMc2tW8bbyYDa2L5IybrtjxJQg4YQp4dHRenfTapqBMBI2T1GqsNnBc3KA2x ppY84ujJe1zBZJu3Jv5S7aNNi6eiue4WyvnfJuDRbV0cJCp2TFMXrLBJzEe/5RuihEYG 3o3ZkPwiDZ0H+XgNIrZBTUen9JFev/MdklsXPyAPXls2XAQ76CCWU5c6zE8cPunWITiD su2A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=e8wpXxCF; 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=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id z19si6117469pfd.397.2018.02.25.20.31.06; Sun, 25 Feb 2018 20:31:22 -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=@linaro.org header.s=google header.b=e8wpXxCF; 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=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752145AbeBZEa1 (ORCPT + 99 others); Sun, 25 Feb 2018 23:30:27 -0500 Received: from mail-pl0-f53.google.com ([209.85.160.53]:40446 "EHLO mail-pl0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752031AbeBZEaY (ORCPT ); Sun, 25 Feb 2018 23:30:24 -0500 Received: by mail-pl0-f53.google.com with SMTP id i6so8606864plt.7 for ; Sun, 25 Feb 2018 20:30:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=NohqUlE/+V+aR3ocr70lW71L2G3m6M7gmVL7/ltFtSM=; b=e8wpXxCFLEaMklWbYVZJ3CNwk6SU2/CjAJHEGhXQCnJ6Y6W9PBxNHkJ+49Fco3SepR ImWkXlBk+N4YnKFtLB1zcEJvGP4Myn9uU14DeoTJERJohyHD7llQ9A5CABPTNEWF3WkB UVkARlZkhdrBESCG0IWO2z21S0JUk3MGqeHkQ= 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:user-agent; bh=NohqUlE/+V+aR3ocr70lW71L2G3m6M7gmVL7/ltFtSM=; b=WZV/rpQUoCLcAPMiqRGSXHqdQXeuZ9OMWbIMCkFIoffqnPozt9yHzpR79vuQrzSxPb AyGnr9JPiL7OBOrnWpICqmZU/LS7YnXzuDf2nibc7ZEzXS+j57jeg75b07BBHdXfsm9T ksKb6ZHZo4mZGQOa07NYgqqPsb5UDueiVJp0UTbL1LsyCltZ7kcWeGKUAXZJ32hZsXOk +i5xfRYFM7KVi+Z+gxmyDB6k4tnBGTmuOkFfKQGf7//QXi9yJBbiPHldYv6w5vMi3fnB hDgYTH8GUwff9QLhMSjrVSEjbjIxIqoJkv7TQJkJ5EB4KWHq566GpvmlV/dRfNPoF198 sA5g== X-Gm-Message-State: APf1xPBQQjiqcegSJ1JH+YmLsO3DFNIf/TCgxaGpVTPSZRC5cyvKfu0B T4ugg41DsQhww7ah/1ePAaMwIA== X-Received: by 2002:a17:902:b183:: with SMTP id s3-v6mr4532243plr.108.1519619423452; Sun, 25 Feb 2018 20:30:23 -0800 (PST) Received: from localhost ([122.172.92.38]) by smtp.gmail.com with ESMTPSA id m3sm13407112pgd.3.2018.02.25.20.30.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Feb 2018 20:30:22 -0800 (PST) Date: Mon, 26 Feb 2018 10:00:21 +0530 From: Viresh Kumar To: Daniel Lezcano Cc: edubezval@gmail.com, kevin.wangtao@linaro.org, leo.yan@linaro.org, vincent.guittot@linaro.org, amit.kachhap@gmail.com, linux-kernel@vger.kernel.org, javi.merino@kernel.org, rui.zhang@intel.com, daniel.thompson@linaro.org, linux-pm@vger.kernel.org Subject: Re: [PATCH V2 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver Message-ID: <20180226043021.GK26947@vireshk-i7> References: <1519226968-19821-1-git-send-email-daniel.lezcano@linaro.org> <1519226968-19821-7-git-send-email-daniel.lezcano@linaro.org> <20180223073432.GF26947@vireshk-i7> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 23-02-18, 12:28, Daniel Lezcano wrote: > On 23/02/2018 08:34, Viresh Kumar wrote: > > On 21-02-18, 16:29, Daniel Lezcano wrote: > >> diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > >> index 5c219dc..9340216 100644 > >> --- a/drivers/thermal/cpu_cooling.c > >> +++ b/drivers/thermal/cpu_cooling.c > >> @@ -10,18 +10,32 @@ > >> * Viresh Kumar > >> * > >> */ > >> +#undef DEBUG > > > > Why is this required ? > > It is usually added, so if you set the -DDEBUG flag when compiling, you > don't get all the pr_debug traces for all files, but the just the ones > where you commented the #undef above. pr_debug is a no-op otherwise. Yeah, but this is a mess as you need to go edit the files before enabling debug with it. Everyone prefers the dynamic debug thing now, where we don't need such stuff. Just drop it. > >> +#define pr_fmt(fmt) "CPU cooling: " fmt > > > > I think you can use the dev_***() routines instead, as you can > > directly the CPU device from anywhere. > > Can we postpone this change for later ? All the file is using pr_* > (cpufreq_cooling included). There is only one place where dev_err is > used but it is removed by the patch 3/7. okay. > >> + while (1) { > >> + s64 next_wakeup; > >> + > >> + prepare_to_wait(&cct->waitq, &wait, TASK_INTERRUPTIBLE); > >> + > >> + schedule(); > >> + > >> + atomic_inc(&idle_cdev->count); > >> + > >> + play_idle(idle_cdev->idle_cycle / USEC_PER_MSEC); > >> + > >> + /* > >> + * The last CPU waking up is in charge of setting the > >> + * timer. If the CPU is hotplugged, the timer will > >> + * move to another CPU (which may not belong to the > >> + * same cluster) but that is not a problem as the > >> + * timer will be set again by another CPU belonging to > >> + * the cluster, so this mechanism is self adaptive and > >> + * does not require any hotplugging dance. > >> + */ > > > > Well this depends on how CPU hotplug really happens. What happens to > > the per-cpu-tasks which are in the middle of something when hotplug > > happens? Does hotplug wait for those per-cpu-tasks to finish ? Missed this one ? > >> +int cpuidle_cooling_register(void) > >> +{ > >> + struct cpuidle_cooling_device *idle_cdev = NULL; > >> + struct thermal_cooling_device *cdev; > >> + struct cpuidle_cooling_tsk *cct; > >> + struct task_struct *tsk; > >> + struct device_node *np; > >> + cpumask_t *cpumask; > >> + char dev_name[THERMAL_NAME_LENGTH]; > >> + int ret = -ENOMEM, cpu; > >> + int index = 0; > >> + > >> + for_each_possible_cpu(cpu) { > >> + cpumask = topology_core_cpumask(cpu); > >> + > >> + cct = per_cpu_ptr(&cpuidle_cooling_tsk, cpu); > >> + > >> + /* > >> + * This condition makes the first cpu belonging to the > >> + * cluster to create a cooling device and allocates > >> + * the structure. Others CPUs belonging to the same > >> + * cluster will just increment the refcount on the > >> + * cooling device structure and initialize it. > >> + */ > >> + if (cpu == cpumask_first(cpumask)) { > > > > Your function still have few assumptions of cpu numbering and it will > > break in few cases. What if the CPUs on a big Little system (4x4) are > > present in this order: B L L L L B B B ?? > > > > This configuration can happen if CPUs in DT are marked as: 0-3 LITTLE, > > 4-7 big and a big CPU is used by the boot loader to bring up Linux. > > Ok, how can I sort it out ? I would do something like this: cpumask_copy(possible, cpu_possible_mask); while (!cpumask_empty(possible)) { first = cpumask_first(possible); cpumask = topology_core_cpumask(first); cpumask_andnot(possible, possible, cpumask); allocate_cooling_dev(first); //This is most of this function in your patch. while (!cpumask_empty(cpumask)) { temp = cpumask_first(possible); //rest init "temp" cpumask_clear_cpu(temp, cpumask); } //Everything done, register cooling device for cpumask. } > >> + np = of_cpu_device_node_get(cpu); > >> + > >> + idle_cdev = kzalloc(sizeof(*idle_cdev), GFP_KERNEL); > >> + if (!idle_cdev) > >> + goto out_fail; > >> + > >> + idle_cdev->idle_cycle = DEFAULT_IDLE_TIME_US; > >> + > >> + atomic_set(&idle_cdev->count, 0); > > > > This should already be 0, isn't it ? > > Yes. I read it as, "I will drop it" :) -- viresh