Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp1627421ybg; Thu, 4 Jun 2020 14:56:10 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwJdhCqXGU+e7l+qco92+iGcr+c1xjrhBnnTMiY9pvHT6mdMumhy2NKEk2DK+odsAUcG25K X-Received: by 2002:a17:907:720f:: with SMTP id dr15mr5698919ejc.486.1591307769918; Thu, 04 Jun 2020 14:56:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591307769; cv=none; d=google.com; s=arc-20160816; b=ZLnG+RXnOOrLMj6CJEQdsUxWc6Kz39zKeXlys6WZe+RfepKaFo69qMS1jofhG0Kiod uA0ZiUuaBNmUG629xL93rjL44uFURN0FhCE4ixPK9i/yup1HgdJ92n6dTFeaUGNon0Na 89IAGCUPv8YjQsEZdA0300W9RfmOPOpUqM7GsXkYcrngaqztDx2dqhe5g9c2WqoQsZBj SV1VkpIYBGbYDUXKUr64vyRgEMzgQ+GIVtHpPtXBFGfCcEa5KNFVpN/SVubb61RezTtm 3MiwDbU4MY+KqWqojyZxnD/U3O/NaWNLlksdto5uq7LarldC+C5FEO3b7k1hHwU4zjp7 qT6w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:message-id :subject:cc:to:from:date; bh=Up8DxDfHSLzKKZ1tK8IaoFJylEJrH0fom/hrAoCfKT8=; b=mDkiWE3Z1xkCF2d/iA78ilZEgbOT052SLEcI8/E7d8ylCunaj2F75+mTnoFfQzD37U oV2FBe6jyCJFvzwS95hWasnKkwATN34I92sxzUodCt8b1EjY5bbfGE0Iv+OwKk03Yezh ls2uq9zVkP9kP8YuNUMv/3Jp4WMUvo/uPBQpE8tHpFGQ9o9uQFgoKk5yb8RftixdVVx2 WK+WR4dU6r1RcYeUfY43FnH3GSR7XqqONGxUtLcCLAeuhLlWimOLjw4nQQDlMI0VW9GI UzKdfxLUjFerrHN5noi7Za3MI63VP2z1j6d7oNaeM9wqHgJvDm9WeQmw76yfQuDVnFVV TBHA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id u10si2512113edb.70.2020.06.04.14.55.45; Thu, 04 Jun 2020 14:56:09 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=ispras.ru Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727813AbgFDV3Z (ORCPT + 99 others); Thu, 4 Jun 2020 17:29:25 -0400 Received: from winnie.ispras.ru ([83.149.199.91]:32068 "EHLO smtp.ispras.ru" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726326AbgFDV3Z (ORCPT ); Thu, 4 Jun 2020 17:29:25 -0400 Received: from monopod.intra.ispras.ru (monopod.intra.ispras.ru [10.10.3.121]) by smtp.ispras.ru (Postfix) with ESMTP id 4A88A203BF; Fri, 5 Jun 2020 00:29:23 +0300 (MSK) Date: Fri, 5 Jun 2020 00:29:23 +0300 (MSK) From: Alexander Monakov To: linux-kernel@vger.kernel.org cc: "Rafael J. Wysocki" Subject: schedutil issue with serial workloads Message-ID: User-Agent: Alpine 2.20.13 (LNX 116 2015-12-14) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, this is a question/bugreport about behavior of schedutil on serial workloads such as rsync, or './configure', or 'make install'. These workloads are such that there's no single task that takes a substantial portion of CPU time, but at any moment there's at least one runnable task, and overall the workload is compute-bound. To run the workload efficiently, cpufreq governor should select a high frequency. Assume the system is idle except for the workload in question. Sadly, schedutil will select the lowest frequency, unless the workload is confined to one core with taskset (in which case it will select the highest frequency, correctly though somewhat paradoxically). This sounds like it should be a known problem, but I couldn't find any mention of it in the documentation. I was able to replicate the effect with a pair of 'ping-pong' programs that get a token, burn some cycles to simulate work, and pass the token. Thus, each program has 50% CPU utilization. To repeat my test: gcc -O2 pingpong.c -o pingpong mkfifo ping mkfifo pong taskset -c 0 ./pingpong 1000000 < ping > pong & taskset -c 1 ./pingpong 1000000 < pong > ping & echo > ping #include #include int main(int argc, char *argv[]) { unsigned i, n; sscanf(argv[1], "%u", &n); for (;;) { char c; read(0, &c, 1); for (i = n; i; i--) asm("" :: "r"(i)); write(1, &c, 1); } } Alexander