From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 6997145B37; Mon, 14 Oct 2024 14:20:14 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 5475C40280; Mon, 14 Oct 2024 14:20:14 +0200 (CEST) Received: from szxga08-in.huawei.com (szxga08-in.huawei.com [45.249.212.255]) by mails.dpdk.org (Postfix) with ESMTP id 131FC4027F for ; Mon, 14 Oct 2024 14:20:10 +0200 (CEST) Received: from mail.maildlp.com (unknown [172.19.162.254]) by szxga08-in.huawei.com (SkyGuard) with ESMTP id 4XRx8S1F1Rz1T8ft; Mon, 14 Oct 2024 20:18:16 +0800 (CST) Received: from kwepemm600004.china.huawei.com (unknown [7.193.23.242]) by mail.maildlp.com (Postfix) with ESMTPS id 1DEDD180106; Mon, 14 Oct 2024 20:20:06 +0800 (CST) Received: from [10.67.121.59] (10.67.121.59) by kwepemm600004.china.huawei.com (7.193.23.242) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Mon, 14 Oct 2024 20:20:05 +0800 Message-ID: Date: Mon, 14 Oct 2024 20:19:35 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: [PATCH v10 1/2] power: introduce PM QoS API on CPU wide To: Stephen Hemminger CC: , , , , , , , , , References: <20240320105529.5626-1-lihuisong@huawei.com> <20240912023812.30885-1-lihuisong@huawei.com> <20240912023812.30885-2-lihuisong@huawei.com> <20241012181030.60d7647a@hermes.local> From: "lihuisong (C)" In-Reply-To: <20241012181030.60d7647a@hermes.local> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [10.67.121.59] X-ClientProxiedBy: dggems706-chm.china.huawei.com (10.3.19.183) To kwepemm600004.china.huawei.com (7.193.23.242) X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Hi Stephen, 在 2024/10/13 9:10, Stephen Hemminger 写道: > On Thu, 12 Sep 2024 10:38:11 +0800 > Huisong Li wrote: > >> + >> +PM QoS >> +------ >> + >> +The deeper the idle state, the lower the power consumption, but the longer >> +the resume time. Some service are delay sensitive and very except the low >> +resume time, like interrupt packet receiving mode. >> + >> +And the "/sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us" sysfs >> +interface is used to set and get the resume latency limit on the cpuX for >> +userspace. Each cpuidle governor in Linux select which idle state to enter >> +based on this CPU resume latency in their idle task. >> + >> +The per-CPU PM QoS API can be used to set and get the CPU resume latency based >> +on this sysfs. >> + >> +The ``rte_power_qos_set_cpu_resume_latency()`` function can control the CPU's >> +idle state selection in Linux and limit just to enter the shallowest idle state >> +to low the delay of resuming service after sleeping by setting strict resume >> +latency (zero value). >> + >> +The ``rte_power_qos_get_cpu_resume_latency()`` function can get the resume >> +latency on specified CPU. >> + > These paragraphs need some editing help. The wording is awkward, > it uses passive voice, and does not seemed directed at a user audience. > If you need help, a writer or AI might help clarify. How about the following description: --> The "/sys/devices/system/cpu/cpuX/power/pm_qos_resume_latency_us" sysfs interface is used to set and get the resume latency limit on the cpuX for userspace. Each cpuidle governor in Linux select which idle state to enter based on this CPU resume latency in their idle task. The deeper the idle state, the lower the power consumption, but the longer the resume time. Some service are delay sensitive and very except the low resume time, like interrupt packet receiving mode. The ``rte_power_qos_set_cpu_resume_latency()`` and ``rte_power_qos_get_cpu_resume_latency()`` can set and get the CPU resume latency based on this per-CPU sysfs. The ``rte_power_qos_set_cpu_resume_latency()`` can control the CPU's idle state selection and limit to enter the shallowest idle state to low the delay of resuming service by setting strict resume latency (zero value) so as to get better performance. > > It also ends up in the section associated with Intel UnCore. > It would be better after the Turbo Boost section. Ack > > > >> + ret = open_core_sysfs_file(&f, "w", PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id); >> + if (ret != 0) { >> + POWER_LOG(ERR, "Failed to open "PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id); >> + return ret; >> + } > The function open_core_sysfs_file() should have been written to return FILE * > and then it could have same attributes as fopen(). Do you mean we should save this handle for directly using it to get or set this resume latency? If it is I understand, we cannot do it like this. Because qos driver in Linux use the "noop_llseek()" as the .llseek API. > > The message should include the error reason. > > if (open_core_sysfs_file(&f, "w", PM_QOS_SYSFILE_RESUME_LATENCY_US, lcore_id)) { > POWER_LOG(ERR, "Failed to open " PM_QOS_SYSFILE_RESUME_LATENCY_US ": %s", > lcore_id, strerror(errno)); Good idea.  Thanks. > > .