From: voidlinux-github@inbox.vuxu.org
To: ml@inbox.vuxu.org
Subject: Re: linux5.5: consider switching from PREEMPT to PREEMPT_VOLUNTARY
Date: Sun, 09 Feb 2020 23:53:12 +0100 [thread overview]
Message-ID: <20200209225312.h4QG4lC0nPvYyKAmNu3cHD5zH5y5BbP2nFo0aTjc5Rc@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: 1511 bytes --]
New comment by ahesford on void-packages repository
https://github.com/void-linux/void-packages/issues/18940#issuecomment-583903951
Comment:
> Not a dev, but I suspect the number of gamers and multimedia users on Void far exceeds the number of ZFS users. For the former, PREEMPT and 1000 Hz tick have definite advantages.
I agree that using full PREEMPT probably provides benefit to gamers. The multimedia benefits depend on the kind of multimedia work being done. Time-sensitive transcoding operations may actually be helped by switching to PREEMPT_VOLUNTARY (or even PREEMPT_NONE) because the reduced emphasis on low latency will not steal computational time from the transcoding operation. (This is more obvious in resource-constrained environments like the [Raspberry Pi](https://github.com/raspberrypi/linux/issues/1216#issuecomment-163200058).)
The ZFS issue brought my attention to this configuration, but it is not the primary motivator for the change. Like I said, I'm sure ZFS on Linux upstream will work around this latest salvo in the GPL/CDDL wars. The real question is where the center of mass is for Void users. Are most of them gamers that will be sensitive to the latency benefits of PREEMPT, are most of them interested in computational throughput that will be sensitive to the throughput costs of PREEMPT (and, to a lesser extent, PREEMPT_VOLUNTARY), or are the centrally clustered or uniformly distributed? The generic kernel ought to target that center of mass as best as possible.
next prev parent reply other threads:[~2020-02-09 22:53 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 [this message]
2020-02-09 23:14 ` voidlinux-github
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=20200209225312.h4QG4lC0nPvYyKAmNu3cHD5zH5y5BbP2nFo0aTjc5Rc@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).