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;
IronPort-SDR: VYTyUCeDZWDyKYS185id1RtOV0Ef1Z5wMyZiRzMtdUJKOOuSk0W11rjPOK2HexK6mX2CvI6RTI
 l9bJZLW5ZCHQ==
IronPort-SDR: 7Arn7IAbvIVYlIlpzd7oXzQ9tQZ2H13N8ezxBepmWVr3of8JU7PwRIaupEp7p+9SDDyua7+/dC
 4PXxKndlm/kA==
Subject: Re: schedutil issue with serial workloads
To:     Alexander Monakov <amonakov@ispras.ru>
References: <alpine.LNX.2.20.13.2006042341160.3984@monopod.intra.ispras.ru>
Cc:     linux-kernel@vger.kernel.org, Linux PM <linux-pm@vger.kernel.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Giovanni Gherdovich <ggherdovich@suse.cz>, qperret@google.com,
        juri.lelli@redhat.com,
        Valentin Schneider <valentin.schneider@arm.com>,
        Vincent Guittot <vincent.guittot@linaro.org>,
        Doug Smythies <dsmythies@telus.net>
From:   "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
Organization: Intel Technology Poland Sp. z o. o., KRS 101882, ul. Slowackiego
 173, 80-298 Gdansk
Message-ID: <c3145e26-56c8-4979-513c-cfac191e989b@intel.com>
Date:   Fri, 5 Jun 2020 18:51:12 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101
 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <alpine.LNX.2.20.13.2006042341160.3984@monopod.intra.ispras.ru>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 6/4/2020 11:29 PM, Alexander Monakov wrote:
> Hello,

Hi,

Let's make more people see your report.

+Peter, Giovanni, Quentin, Juri, Valentin, Vincent, Doug, and linux-pm.

> 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).

That's because the CPU utilization generated by the workload on all CPUs 
is small.

Confining it to one CPU causes the utilization of this one to grow and 
so schedutil selects a higher frequency for it.

> This sounds like it should be a known problem, but I couldn't find any
> mention of it in the documentation.

Well, what would you expect to happen instead of what you see?


> 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 <stdio.h>
> #include <unistd.h>
> 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