Received: by 10.223.176.5 with SMTP id f5csp1147470wra; Wed, 31 Jan 2018 01:57:35 -0800 (PST) X-Google-Smtp-Source: AH8x226G3tk+1HknlTXS9HaZj3hW9tOJnf8Mk4bXSbUqXXllAAkOLlpZzPQ7cq4d/Roe/CoivB7F X-Received: by 10.101.75.141 with SMTP id t13mr26834668pgq.232.1517392655058; Wed, 31 Jan 2018 01:57:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517392655; cv=none; d=google.com; s=arc-20160816; b=tFZinbUwL2H39ht5nygNJ1fDoIop6enOVY8jBZYU5Wns+T97sYKy/xRs3KkYACfvVQ hOF0kpYooVutZuLavzac6S6NvEgVJe1Fmpb+K2n75S9ROVIt2gbhOv1xY8Xx5uY02Mgn kqyiwa8dzYIqbFP5ZERnjTjL/Xyxwr4G056MkJWxK9qJ29cLb8gCRMoN33EXZaMWnlTZ n1Qf7mZ0qwhbC0isgJv1GMxiNYV9b85bH3/oUSVF99ugk4squku0fzOVdb0yFPwAityJ fhpAZF9OxbEBi6TuqFD9AxGIWI6CrJfxyX6dMZKj4TC3OuyD+Wg7EmzqTMWPLkC3jb0W CaSQ== 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:cc:to:subject :message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=QYegoXXuv5WkL7ZlP0XCbeflIXVmbt+MW8+qFlRI9Rc=; b=Intka2ZgB1/dSMxqzuG3GZ5qjUPRUsWBOLffBkPqx6lfnfyVJf2u5LGWiNP2KKHgbb BE2PIdmCYPsdoAza7Ga9JUSitz8AKWXAJiZQReomScc6YNdTuU5xiGHcyw9/6b1BUGEk m5f7+GOY7VP3/JTYeO8i3L87ua30k96O/q6gD3k6EUJ9lSbZXOvoRU8sgS3qPV0YFGA/ uB2VHRp+HMeMZ04MS3Zwrpy6nF179V8PCmei6gBXDWitYTtcphJMQZQ6Iy9DdGbORgVj Z+vTpQGpVeV+VG3C2mKCshRdekQgT4JTCH1YabsSr4XEM/3Xek7W6WG5Q8xdoG6/ukNR bQzw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=feOIyMaX; 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 61-v6si3640102pla.333.2018.01.31.01.57.20; Wed, 31 Jan 2018 01:57:35 -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=feOIyMaX; 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 S1752638AbeAaJ4z (ORCPT + 99 others); Wed, 31 Jan 2018 04:56:55 -0500 Received: from mail-it0-f68.google.com ([209.85.214.68]:54380 "EHLO mail-it0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751435AbeAaJ4w (ORCPT ); Wed, 31 Jan 2018 04:56:52 -0500 Received: by mail-it0-f68.google.com with SMTP id k131so4596604ith.4 for ; Wed, 31 Jan 2018 01:56:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=QYegoXXuv5WkL7ZlP0XCbeflIXVmbt+MW8+qFlRI9Rc=; b=feOIyMaX9n7aTsvYHhLlnDIpGL+JIxnd9Qlr6fyi4x4TPcfitfWyXSHWg8Cn8ObwA3 4WVoLrsrqXGOt1ZSb5Ms3V8Va9Cz0cfAecC9kgjwCV6txty8Xn4UMihIxC7yNQcOVtuh AjqdLv7KDjtq/JiXA8txtD++WKK6EJRdXzrVM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QYegoXXuv5WkL7ZlP0XCbeflIXVmbt+MW8+qFlRI9Rc=; b=X96A8Z1krZyqRxTxbDc4tbZLacYnQvwUTptgn3mQYEGNJ1GzO4bPclLAspP9L1Z6ac +o01noOR7/OJpN+BnJoAMurXaAJ1G9VZtuTHeWbnFRfcGhJmVOsi8F8QaThxRSoGsNu3 jJI/6BvCReWlOv4+9qhjwPXTSinRCOLZ/QqIZSpSOm6ax6OVLs4l7kEzrbomaKymYIij 9eIlV4L2VaC4o+wwA9ckSrsoHA2FzPg3/VCzDirtsxowXTDEApjKlJoT6m00oIkdDB6i fQjehEjEL7XuPk4r8HTkx82Rg9yd4JCoYDS7e0Tj7fNl5mTMb5w+UtXP8LZ1bcrsnMcC b4+g== X-Gm-Message-State: AKwxytdRkoZaYECugFqy7e/pUG20mTdXErqxSIXmLhA3nlnmRmr1bXBD z6nHqpk6djofW/X1sUPPW7OB3PWlsxv4rml+S8tu6w== X-Received: by 10.36.101.15 with SMTP id u15mr883608itb.74.1517392612064; Wed, 31 Jan 2018 01:56:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.50.198 with HTTP; Wed, 31 Jan 2018 01:56:31 -0800 (PST) In-Reply-To: <6e776e6c-6f1e-b33b-58b7-b95410ca1f95@linaro.org> References: <1516721671-16360-1-git-send-email-daniel.lezcano@linaro.org> <1516721671-16360-6-git-send-email-daniel.lezcano@linaro.org> <11334876-ef8c-58fa-5e32-ab8499eebd7e@linaro.org> <6e776e6c-6f1e-b33b-58b7-b95410ca1f95@linaro.org> From: Vincent Guittot Date: Wed, 31 Jan 2018 10:56:31 +0100 Message-ID: Subject: Re: [PATCH 5/8] thermal/drivers/cpu_cooling: Introduce the cpu idle cooling driver To: Daniel Lezcano Cc: Eduardo Valentin , Kevin Wangtao , Leo Yan , Amit Kachhap , viresh kumar , linux-kernel , Zhang Rui , Javi Merino , "open list:THERMAL" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 31 January 2018 at 10:50, Daniel Lezcano wro= te: > On 31/01/2018 10:46, Vincent Guittot wrote: >> On 31 January 2018 at 10:33, Daniel Lezcano = wrote: >>> On 31/01/2018 10:01, Vincent Guittot wrote: >>>> Hi Daniel, >>>> >>>> On 23 January 2018 at 16:34, Daniel Lezcano wrote: >>> >>> [ ... ] (please trim :) >>> >>>>> + /* >>>>> + * Each cooling device is per package. Each package >>>>> + * has a set of cpus where the physical number is >>>>> + * duplicate in the kernel namespace. We need a way t= o >>>>> + * address the waitq[] and tsk[] arrays with index >>>>> + * which are not Linux cpu numbered. >>>>> + * >>>>> + * One solution is to use the >>>>> + * topology_core_id(cpu). Other solution is to use th= e >>>>> + * modulo. >>>>> + * >>>>> + * eg. 2 x cluster - 4 cores. >>>>> + * >>>>> + * Physical numbering -> Linux numbering -> % nr_cpus >>>>> + * >>>>> + * Pkg0 - Cpu0 -> 0 -> 0 >>>>> + * Pkg0 - Cpu1 -> 1 -> 1 >>>>> + * Pkg0 - Cpu2 -> 2 -> 2 >>>>> + * Pkg0 - Cpu3 -> 3 -> 3 >>>>> + * >>>>> + * Pkg1 - Cpu0 -> 4 -> 0 >>>>> + * Pkg1 - Cpu1 -> 5 -> 1 >>>>> + * Pkg1 - Cpu2 -> 6 -> 2 >>>>> + * Pkg1 - Cpu3 -> 7 -> 3 >>>> >>>> >>>> I'm not sure that the assumption above for the CPU numbering is safe. >>>> Can't you use a per cpu structure to point to resources that are per >>>> cpu instead ? so you will not have to rely on CPU ordering >>> >>> Can you elaborate ? I don't get the part with the percpu structure. >> >> Something like: >> >> struct cpuidle_cooling_cpu { >> struct task_struct *tsk; >> wait_queue_head_t waitq; >> }; >> >> DECLARE_PER_CPU(struct cpuidle_cooling_cpu *, cpu_data); > > I got this part but I don't get how that fixes the ordering thing. Because you don't care of the CPU ordering to retrieve the data as they are stored per cpu directly > > > -- > Linaro.org =E2=94=82 Open source software for A= RM SoCs > > Follow Linaro: Facebook | > Twitter | > Blog >