All of lore.kernel.org
 help / color / mirror / Atom feed
From: Julia Lawall <julia.lawall@inria.fr>
To: Waiman Long <longman@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will.deacon@arm.com>, Ingo Molnar <mingo@redhat.com>,
	linux-kernel@vger.kernel.org,
	Gilles Muller <Gilles.Muller@inria.fr>
Subject: slowdown due to reader-owned rwsem time-based spinning
Date: Thu, 15 Oct 2020 13:38:31 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2010151315190.2869@hadrien> (raw)

[-- Attachment #1: Type: text/plain, Size: 1382 bytes --]

Hello,

Phoenix is an implementation of map reduce:

https://github.com/kozyraki/phoenix

The phoenix-2.0/tests subdirectory contains some benchmarks, including
word_count.

At the same time, on my server, since v5.8, the kernel has changed from
using the governor intel_pstate by default to using intel_cpufreq.
Intel_cpufreq causes kworkers to run on all cores every 0.004 seconds,
while intel_pstate involves very few such stray processes.

Suprisingly, all those kworkers cause the word_count benchmark to run 2-3
times faster.  I bisected the problem back to the following commit, whcih
was introduced in v5.3:

commit 7d43f1ce9dd075d8b2aa3ad1f3970ef386a5c358
Author: Waiman Long <longman@redhat.com>
Date:   Mon May 20 16:59:13 2019 -0400

    locking/rwsem: Enable time-based spinning on reader-owned rwsem

Representative traces are attached.  word_count_5.9pwrsvpassive_1.pdf is
the one with the kworkers.

I don't know the Phoenix code in detail, but the problem seems to be in
the infrastructure not the specific word count aplication, because most of
the benchmarks seem to suffer similarly.  Some of the other benchmarks
seem to take a variable and long amount of time to get started in the
active mode, so perhaps the problem could be in reading the initial
dataset.

Before I plunge into it, do you have any suggestions as to what could be
the problem?

thanks,
julia

[-- Attachment #2: Type: application/pdf, Size: 1511252 bytes --]

[-- Attachment #3: Type: application/pdf, Size: 1797989 bytes --]

             reply	other threads:[~2020-10-15 12:01 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-15 11:38 Julia Lawall [this message]
2020-10-19 19:33 ` slowdown due to reader-owned rwsem time-based spinning Waiman Long
2020-10-19 19:48   ` Julia Lawall
2020-10-20  3:09     ` Waiman Long
2020-10-20  6:16       ` Julia Lawall

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=alpine.DEB.2.22.394.2010151315190.2869@hadrien \
    --to=julia.lawall@inria.fr \
    --cc=Gilles.Muller@inria.fr \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will.deacon@arm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.