linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
To: Alexander Monakov <amonakov@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>
Subject: Re: schedutil issue with serial workloads
Date: Fri, 5 Jun 2020 18:51:12 +0200	[thread overview]
Message-ID: <c3145e26-56c8-4979-513c-cfac191e989b@intel.com> (raw)
In-Reply-To: <alpine.LNX.2.20.13.2006042341160.3984@monopod.intra.ispras.ru>

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



  reply	other threads:[~2020-06-05 16:51 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-04 21:29 schedutil issue with serial workloads Alexander Monakov
2020-06-05 16:51 ` Rafael J. Wysocki [this message]
2020-06-05 18:35   ` Alexander Monakov
2020-06-05 20:33   ` Peter Zijlstra
2020-06-07 17:24   ` Doug Smythies

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c3145e26-56c8-4979-513c-cfac191e989b@intel.com \
    --to=rafael.j.wysocki@intel.com \
    --cc=amonakov@ispras.ru \
    --cc=dsmythies@telus.net \
    --cc=ggherdovich@suse.cz \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=qperret@google.com \
    --cc=valentin.schneider@arm.com \
    --cc=vincent.guittot@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).