Received: by 10.213.65.68 with SMTP id h4csp538535imn; Tue, 13 Mar 2018 12:16:59 -0700 (PDT) X-Google-Smtp-Source: AG47ELsVm6NEikm9ju/Kb1Cv7if8+/mC1h3pfdGyYi61qg9R3Xp1Vb2GjullcdLuZv1MN4Yl0tVO X-Received: by 10.98.88.5 with SMTP id m5mr1615295pfb.231.1520968619469; Tue, 13 Mar 2018 12:16:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520968619; cv=none; d=google.com; s=arc-20160816; b=fA5XsgVUSRcYYMWJXd4YvTL6+ic2EEwzgu/nKwneyMAmlIm45O+luaxhjagbpo7+Co 91cMNqR8vJG1xBYIgwRT9DRNzUu4NJNXbtRX14KF8DM4ibfgAxZ+/jfQHoWmC6vSRJPO 19qXfZzOOA6KuQ2XrMXwKaaxySEns13VK4nzx5EgwWbfBmTPG3eh3MajMHJYbBGTSEvx w6EZmT9chxlo6mUBJJqLxXI0aXMhMngKy8c8VWX5gkF/tcfd9osenx1zqwCJHggk2Ykx AiyxXUAhheSz/X5U+ysfFZT8reD0BxtvPdgZI9ByS+lwCwQeooMef6rsVfSmGqNK7Tcy xB/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature :arc-authentication-results; bh=VyUyrglYhzk/o4v/A1SxcwEght0DA4KrZIbMZ/tVNfk=; b=F1hSD5eIItoMLfNWMZBau84W70il12FEEenX0xmCdZFWaLsyNDFB8Gf+JYsZVehEAO 4GWXrF4/9QYGmgnRFnpwHbsIL3VLlhaZAcELsmC+Xkg6rbfuT5pgrC+7BHMttsGmfCvE qZD9gbx6Z0x52w0H3y2pjUMuIySu4ubmXJSvzFJ6KDoHcCJiLSaijJn3HwQ4FD4Hat4v uwsvstyDSlL8rdoxoCD7/3uy0SOxFd0San0k2KtMMKWAbB4tCJ+DrkMvUlR0u6pwSeys 6h9n6Oq2CjwlO0NfV0aXpq1WdOGKCqNumxhAEneWE10MZ5IBo9aTnb5ymlZPKdONc5yL z20Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=LVBmSUwt; 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 j5si526876pgp.193.2018.03.13.12.16.44; Tue, 13 Mar 2018 12:16:59 -0700 (PDT) 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=LVBmSUwt; 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 S1752431AbeCMTPm (ORCPT + 99 others); Tue, 13 Mar 2018 15:15:42 -0400 Received: from mail-wr0-f170.google.com ([209.85.128.170]:33097 "EHLO mail-wr0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751534AbeCMTPk (ORCPT ); Tue, 13 Mar 2018 15:15:40 -0400 Received: by mail-wr0-f170.google.com with SMTP id r8so2076084wrg.0 for ; Tue, 13 Mar 2018 12:15:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=VyUyrglYhzk/o4v/A1SxcwEght0DA4KrZIbMZ/tVNfk=; b=LVBmSUwtyWa64Ei+nOdtLfgSmiVyGH26+zPQVEi7BWP2Y6P9L4r1QNfSXVc47OKsY+ V6K/nkQHBMcibyX1Tz/xn1cJetlQMpAc7fk6SaZCbgRQ+D+XxTqkhnXLA/o+n2foHDKp uPdC53qUa3OF5rxsqittPmH/d0+VTqfdPHpYY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=VyUyrglYhzk/o4v/A1SxcwEght0DA4KrZIbMZ/tVNfk=; b=AjgTKI7O9e1v6XyU5+IanfBBmGRhyx+La0pQAx+6Q5Dk5chy9RSVEj8Q2cZ8CW8VvI 5/Tu+h6rPX1ovZNUKisgCxCZs4WKhoioMkxrdjeqDzN8+c0EYAcOxg11salgsJ7jpURq SHxZKDU7f7b4tBU6mXHj4m8543NwzjMKjxTM8sfXOzrLcNGwBLvXFVkdfLrd/25oLAoz DqBvONkJS/jkAWRSRAwQvS2ii9SO1HgdNPkwB8gddZi/mCA94gq0Z6QZxXq8T4CmIt4p XEOpcLM7QHmbbBVbIBOwHoPRBvBjGL3fS2nF4ANd1/NTVsvXZulXu6ZV7KizxERfQmxu OxQg== X-Gm-Message-State: AElRT7FozDyivLkg7NDoeII3S4P+gmpMlic8MfAUoJZZHjEXl4icgvEI fzRYnkFuXd0SIKcN4H0ucp+m3Q== X-Received: by 10.223.128.209 with SMTP id 75mr1594531wrl.108.1520968539234; Tue, 13 Mar 2018 12:15:39 -0700 (PDT) Received: from ?IPv6:2001:41d0:fe90:b800:f05c:9eb7:1dd5:d715? ([2001:41d0:fe90:b800:f05c:9eb7:1dd5:d715]) by smtp.googlemail.com with ESMTPSA id o24sm1145090wmi.29.2018.03.13.12.15.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Mar 2018 12:15:38 -0700 (PDT) Subject: Re: [PATCH V2 6/7] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver To: Viresh Kumar 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 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> <20180226043021.GK26947@vireshk-i7> From: Daniel Lezcano Message-ID: Date: Tue, 13 Mar 2018 20:15:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180226043021.GK26947@vireshk-i7> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 26/02/2018 05:30, Viresh Kumar wrote: [ ... ] >>>> + /* >>>> + * 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 ? To be frank, I don't know. I have been through the hp code and didn't find the answer. AFAICT, the sched/core.c sched_cpu_dying() disables the rq and then migrates the tasks. I assume this kthread is not migrated and stays in sleeping state until the rq is online again. As the wakeup callback discards offline cpus, the kthread is not wakeup at any moment. I created a situation where that happens: mitigation (raised with dhrystone) + cpu hotplugging (offline/online loop) and never hit any issue. However, I'm wondering if using the 'struct smp_hotplug_thread' infra-stucture (git show f97f8f06) shouldn't be used. >>>> +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" :) > -- Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog