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@xxxxxxx >> <mailto:be.0@xxxxxxx>> 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/music]> >> 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@xxxxxxxxxxxxxxxxxxxxxxx <mailto:music@xxxxxxxxxxxxxxxxxxxxxxx> >> https://admin.fedoraproject.org/mailman/listinfo/music >> > _______________________________________________ > music mailing list > music@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/music _______________________________________________ music mailing list music@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/music
