From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: linux5.5: consider switching from PREEMPT to PREEMPT_VOLUNTARY
Date: Mon, 10 Feb 2020 00:14:00 +0100 [thread overview]
Message-ID: <20200209231400.660eH9XJ7Cl3zpQENVUnajrqs7BcdAOh-vRO5S-vobU@z> (raw)
In-Reply-To: <gh-mailinglist-notifications-41a7ca26-5023-4802-975b-f1789d68868e-void-packages-18940@inbox.vuxu.org>
[-- Attachment #1: Type: text/plain, Size: 1473 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/18940#issuecomment-583905912
Comment:
> I was never able to see much of a difference in responsiveness between `PREEMPT_VOLUNTARY` and `PREEMPT` tbh.
>
> BTW, the non-x86 kernels are generally configured to use `PREEMPT_VOLUNTARY` (with 250 Hz tick, 100 for aarch64) already. Also when I was configuring the PowerPC kernels, it turned out that using `PREEMPT` results in the kernels not booting at all on a fair amount of machines... that said, I'm not seeing any responsiveness issues on those either.
This seems to argue in favor of switching to PREEMPT_VOLUNTARY. Anecdotally, on a Ryzen 5 3600 six-core (twelve-thread) system, I've seen no unacceptable latency using a custom 5.5.2_2 config that uses PREEMPT_VOLUNTARY and HZ_250 while watching a (software-decoded) 3840x1920@30fps VP9 video (generally burning around 100% CPU) from YouTube and playing a 256 kbps AAC audio stream through cmus while typing this response and doing some mousing around during a 12-thread [cyclictest]( https://git.kernel.org/pub/scm/linux/kernel/git/clrkwllms/rt-tests.git) latency benchmark. The *maximum* latency measurements on each core during this testing was, in **micro**sec:
1189, 1113, 1067, 884, 766, 166, 150, 142, 135, 128, 118, 78
while the average latencies were all 1 or 2 microsec.
Again, this is one anecdote. Everybody will have a unique story.
next prev parent reply other threads:[~2020-02-09 23:14 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-08 15:01 [ISSUE] " voidlinux-github
2020-02-09 15:49 ` voidlinux-github
2020-02-09 16:28 ` voidlinux-github
2020-02-09 16:29 ` voidlinux-github
2020-02-09 22:53 ` voidlinux-github
2020-02-09 23:14 ` voidlinux-github [this message]
2020-02-10 7:29 ` voidlinux-github
2020-02-10 7:44 ` voidlinux-github
2020-02-10 8:12 ` voidlinux-github
2020-02-10 8:22 ` voidlinux-github
2020-02-10 8:34 ` voidlinux-github
2020-02-10 9:21 ` voidlinux-github
2020-02-10 10:34 ` voidlinux-github
2020-02-10 13:08 ` voidlinux-github
2020-02-10 13:09 ` voidlinux-github
2020-02-10 14:10 ` voidlinux-github
2020-02-10 14:15 ` voidlinux-github
2020-02-11 9:08 ` voidlinux-github
2020-02-11 9:17 ` voidlinux-github
2020-02-11 11:10 ` voidlinux-github
2020-02-11 11:13 ` voidlinux-github
2020-02-11 16:59 ` voidlinux-github
2020-02-11 17:40 ` voidlinux-github
2020-02-11 17:41 ` voidlinux-github
2020-02-12 14:14 ` [ISSUE] [CLOSED] " voidlinux-github
2020-02-12 14:14 ` voidlinux-github
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=20200209231400.660eH9XJ7Cl3zpQENVUnajrqs7BcdAOh-vRO5S-vobU@z \
--to=voidlinux-github@inbox.vuxu.org \
--cc=ml@inbox.vuxu.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).