mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Laight <David.Laight@ACULAB.COM>
To: 'Linus Torvalds' <torvalds@linux-foundation.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: RE: Linux 6.10-rc2 - massive performance regression
Date: Sat, 8 Jun 2024 14:44:12 +0000	[thread overview]
Message-ID: <46cb50d65e414bfd9bef5549d68ae4ea@AcuMS.aculab.com> (raw)
In-Reply-To: <CAHk-=wisJ8bS3qe6iBPwL9x=PqJA5oE7tum-E9oZfyPgd2mmrw@mail.gmail.com>

I'm seeing a massive performance regression in 6.10-rc2 compared to 6.9-rc4.
I suspect the change is in 6.10-rc1

Some code that is (ought to be) mostly userspace is taking about 2.5 times
longer to run (30 minutes instead of 12).

The program will be pretty much running in userspace (fpga vhdl compiler).

I suspect it is due to the changes to the way the scheduler pre-empts
processes.

What make all the difference is an idle daemon that is pretty much
doing:
Thread 1:
	for (;;) {
		poll(0, 0, 10);
		pthread_cond_broadcast(cv); // [1]
	}
Threads 2+ (total one for each cpu):
	for (;;) {
		pthread_cond_wait(cv, mtx);
	}
ie all the threads wake up every 10ms, find there is nothing
to do and go back to sleep.
(They would be processing TDM or RTP audio.)

My suspicion is that threads 2+ are looping in the futex() call
until a scheduler timer tick instead of actually sleeping and
letting anything else run.

For this configuration all the daemon threads are running under the
default scheduler, but it usually better to run them at a low RT priority.

I can't remember whether there is a sysctl to change the scheduler behaviour,
but the current default is badly broken for some workloads.

	David

[1] It isn't that simple, the broadcast only wakes one thread which then
wakes the next (etc). Not only do the delay getting the cpu out of sleep
states accumulate, but if any thread can't run (eg if they are RT and the
cpu is busy) none of the later ones wake up.
So, in fact, there is a separate cv for each thread and the woken threads
also issue wakeups.
But that is all a different problem...)

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

  parent reply	other threads:[~2024-06-08 14:44 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-02 22:50 Linux 6.10-rc2 Linus Torvalds
2024-06-03  7:03 ` Build regressions/improvements in v6.10-rc2 Geert Uytterhoeven
2024-06-08 14:44 ` David Laight [this message]
2024-06-08 16:02   ` Linux 6.10-rc2 - massive performance regression Linus Torvalds
2024-06-08 21:35     ` David Laight
2024-06-08 22:00       ` Linus Torvalds
2024-06-08 22:28         ` Woody Suwalski
2024-06-09  8:07         ` Johan Hovold
2024-06-09  8:11         ` Linux regression tracking (Thorsten Leemhuis)
2024-06-09  9:35           ` David Laight
2024-06-09 14:24         ` David Laight

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=46cb50d65e414bfd9bef5549d68ae4ea@AcuMS.aculab.com \
    --to=david.laight@aculab.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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

all inboxes | Powered by JetHome®