Here's a diff of between the configs of Ubuntu's generic and lowlatency
linux-image (amd64) packages:
$ diff config-generic config-lowlatency
3c3
< # Linux/x86_64 3.19.0-12-generic Kernel Configuration
---
# Linux/x86_64 3.19.0-12-lowlatency Kernel Configuration
69c69
< CONFIG_VERSION_SIGNATURE="Ubuntu 3.19.0-12.12-generic 3.19.3"
---
CONFIG_VERSION_SIGNATURE="Ubuntu 3.19.0-12.12-lowlatency
3.19.3"
96c96
< # CONFIG_IRQ_FORCED_THREADING_DEFAULT is not set
---
CONFIG_IRQ_FORCED_THREADING_DEFAULT=y
135c135
< CONFIG_TREE_RCU=y
---
CONFIG_PREEMPT_RCU=y
145a146
# CONFIG_RCU_BOOST is not set
251d251
< CONFIG_OPTPROBES=y
381,385d380
< CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
< CONFIG_INLINE_READ_UNLOCK=y
< CONFIG_INLINE_READ_UNLOCK_IRQ=y
< CONFIG_INLINE_WRITE_UNLOCK=y
< CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
457,458c452,454
< CONFIG_PREEMPT_VOLUNTARY=y
< # CONFIG_PREEMPT is not set
---
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
565c561
< CONFIG_HZ_250=y
---
# CONFIG_HZ_250 is not
set
567,568c563,564
< # CONFIG_HZ_1000 is not
set
< CONFIG_HZ=250
---
CONFIG_HZ_1000=y
CONFIG_HZ=1000
4998d4993
< CONFIG_DRM_I810=m
7487a7483
# CONFIG_DEBUG_PREEMPT is not set
7551a7548
# CONFIG_PREEMPT_TRACER is not set
So it looks like the big differences with the lowlatency config are
enabling CONFIG_PREMPT, CONFIG_IRQ_FORCED_THREADING_DEFAULT, and
CONFIG_PREEMPT_RCU as well as setting CONFIG_HZ to 1000. Would using
these settings in a Fedora kernel have the stability concerns as the RT
patch set? Would there be any other drawbacks?
On 04/05/2015 12:21 PM, Be wrote:
Has anyone looked into what Ubuntu Studio is doing with the
lowlatency
kernel? Would it be feasible to include a similarly configured kernel in
Fedora?
On 11/13/2014 10:59 AM, Brian Monroe wrote:
> I think so too, thanks for chiming in.
>
> I'm still waiting to get into the packagers group, but I have a koji
> account and theoretically could compile an rt kernel. I think the
> standard naming schema in other distros is kernel-rt. It should be
> only adding a few lines to the spec file to enable the rt kernel, but
> when you look at how many kernel update there are for Fedora every
> week, I'm not sure as to how up to date we'll be able to keep up due
> to the work load. We're already are down on developers, and people
> like Brandon are keeping us afloat.
>
> Are we going to be ok as a project to be behind a week or two in
> Kernel releases? Personally I'm for more stable kernels when it comes
> to music production vs. having the latest and greatest, but I also
> think that should be a clearly indicated as a feature
>
> That being said, I feel strongly as though others should take this
> task on, if not me, then someone else or better yet, a few of us.
>
>
> I'm looking into the Ubuntu Studio and turns out they dropped the RT
> kernel as default. They're using a "lowlatency" kernel instead of a rt
> kernel (though they do still supply an rt kernel but not by default).
> I do know that users are able to get 1.5 ms latency with zero xruns so
> I'm guessing they're doing something other than real-time scheduling,
> I just don't know what. Thoughts?
>
> On Wed Nov 12 2014 at 10:40:44 AM Be Ing <be.0(a)gmx.com
> <mailto:be.0@gmx.com>> wrote:
>
> Hello Fedora musicians, I've been lurking this list for a little
> bit and this is my first time chiming in on something.
>
> I think it is important to pursue an official realtime kernel for
> Fedora. I think a distribution focused on audio without a realtime
> kernel would have a serious bug, that IMO, would be worth delaying
> publication for.
>
> >So I had a beer with hansomepirate(jdulaney), who is, or was on
> the kernel
> sig, last night and we got to talking about a RT kernel.
> >
> >Last time we talked to the kernel folks about an rt kernel, they
> weren't
> impressed with the "need" for Fedora, but that was before the Spin was
> officially out.
> >
> >Now might be a good time to raise this issue again? I dug through my
> archives and found this thread. Now that we have an actual spin
> that's out,
> we can actually redo some of the testing to have more realistic tests.
> (multitrack with effects)
> >
> >I feel like right now, it's one of the few benefits that the
> ubuntu studio
> folks have (or at least claim to have) over us. The other is some
> semi-proprietary software that on... you know what, never mind
> it's getting
> off topic.
> >
> >Anyways, does the list think this is worth pursuing?
> >
> >>On Wed Feb 22 2012 at 9:10:29 PM Brian Monroe <briancmonroe at
>
gmail.com
>
<
http://gmail.com>[https://admin.fedoraproject.org/mailman/listinfo/mus...
> wrote:
> >>
> >> Ok, I redid all the tests, while the system was only running my
> DE and the
> >> test, and then again when I put it under duress by running a
> script that
> >> looped "du -h /" and "ls -Ral /usr/" over and over.
I ran the
> script twice
> >> to get my proc up a bit to emulate running some intese delays
> and reverbs
> >> or other effects.
> >>
> >> Ironically the kernels typically did better when the scripts
> were running.
> >> Personally I think there's a clear advantage with CCRMA's
> kernel or even
> >> just a preempt kernel in the max lat areas. Those max numbers
> jumped up
> >> close to where they were near the beggining of the test if
> anyone was
> >> wondering.
> >>
> >> Here's the file with both sets of tests and the uname -a info
> as requested
> >> by Fernando.
> >> -Brian
> >>
> >>> On Wed, Feb 22, 2012 at 6:54 AM, Brian Monroe <briancmonroe at
>
gmail.com
> <
http://gmail.com>[https://admin.fedoraproject.org/mailman/listinfo/music]
> >>> wrote:
> >>> I'll be sure to include that on the next batch. I used the
> kernel you
> >>> after installing the CCRMA repo when you use yum install
> kernel-rt, which
> >>> happens to be 3.0.17-1.rt33.1.fc16.ccrma.x86_64.rt. I'll go
> back and
> >>> include the other info to the old results when I do the load
> testing
> >>> tonight or tomorrow.
> _______________________________________________
> music mailing list
> music(a)lists.fedoraproject.org <mailto:music@lists.fedoraproject.org>
>
https://admin.fedoraproject.org/mailman/listinfo/music
>
_______________________________________________
music mailing list
music(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/music