4 Nov
2016
4 Nov
'16
9:51 a.m.
Hello, two quick questions:
* Is there someone here using Ubuntu (16.04 LTS) with a hard RT
PREEMPT kernel?
* Can he tell me how to obtain it? Probably not pre-built from a
repository/ppa, I've done my homework and found two that seem
nothing but dead :
o https://launchpad.net/~abogani/+ppa-packages
o https://launchpad.net/~linux-libre/+archive/ubuntu/rt-ppa
Otherwise, I guess I'll have to build it. Never done it. I've compiled
all sort of stuff, but never a kernel. Now what would be the easiest
way? By easy, in fact, I only mean scriptable. Ideally something like
* Get the latest kernel sources package with apt
* Fetch the corresponding patch (this is the hard part for me, I'm a
bit lost in versions)
* Apply the patch, build the kernel and install it
The idea being to be able to repeat the procedure when a new kernel is
out in the lifespan of my Ubuntu version, to stay up to date.
Any pointers? Thanks for your patience. Note that if I manage to get a
fairly repeatable procedure, I'll write a tutorial about it. Cordialement,
yPhil
--
Yassin Philip
http://yassinphilip.bitbucket.org
4 Nov
4 Nov
11:11 a.m.
Hi,
use export CONCURRENCY_LEVEL=[...] if you want to build with
several jobs. You could use fake root, if you dislike to build with
root privileges. However, this are the commands you need to run, when
building with root privileges.
Replace [...] with what's missing, use a browser to visit those sites.
The rt patch must exactly fit to the kernel version.
wget https://www.kernel.org/pub/linux/kernel/[...].tar.gz
wget https://www.kernel.org/pub/linux/kernel/projects/rt/[...].patch.gz
sudo -i
Extract the kernel
tar zxf linux-[...]
Rename the extracted directory to the rt name
mv linux-[...] linux-[...]-rt[...]
Change into the extracted directory and patch the kernel.
cd linux-[...]-rt[...]
gzip -dc ../patch-[...].patch.gz | patch -p1
Copy the config of e.g. an Arch rt kernel or the config of the non-rt
you are running to the directory
https://aur.archlinux.org/cgit/aur.git/snapshot/linux-rt.tar.gz
https://aur.archlinux.org/cgit/aur.git/snapshot/linux-rt-lts.tar.gz
respectively
cp /boot/config-$(uname -r) config
Configure the kernel
make oldconfig
Build the kernel
make-kpkg clean
make-kpkg --initrd kernel-image kernel-headers
Building the kernel most likely fails two or three times, you most
likely need to disable a few configurations. To do this read the error
messages and use
make menuconfig
it has got a search option, so you easily could find what to disable,
OTOH sometimes it's faster to use an editor and directly disable an
option.
Repeat running
make oldconfig
make-kpkg clean
make-kpkg --initrd kernel-image kernel-headers
Use apt install or dpkg -i to install the packages.
This is the Debian way to build a kernel, that works without failure for
Ubuntu, too. Actually there's an Ubuntu way that is a little bit different.
This is how I successfully build rt patched kernels for Ubuntu countless
times.
If you should be inexperienced in configuring a kernel, 1. oldconfig's and
menuconfig's help, 2. Google and 3. this list are your friends, in exactly
that order ;).
Regards,
Ralf
11:35 a.m.
On 04/11/2016 10:11, Ralf Mardorf wrote:
Hi,
use export CONCURRENCY_LEVEL=[...] if you want to build with
several jobs. You could use fake root, if you dislike to build with
root privileges. However, this are the commands you need to run, when
building with root privileges.
(...)
This is the Debian way to build a kernel, that works
without failure for
Ubuntu, too. Actually there's an Ubuntu way that is a little bit different.
This is how I successfully build rt patched kernels for Ubuntu countless
times.
If you should be inexperienced in configuring a kernel, 1. oldconfig's and
menuconfig's help, 2. Google and 3. this list are your friends, in exactly
that order ;).
Regards,
Ralf
Thanks, nice procedure, quite straightforward (what would be the
differences in "the Ubuntu way"?) But I was really hoping to be able to
automate all this, alas the menuconfig phase always require human
intervention... Is there really no way to just (de)select the options
you need, programmatically?
Phil
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Yassin Philip - New album out NOW
http://yassinphilip.bitbucket.org
11:50 a.m.
On Fri, 4 Nov 2016 10:35:12 +0000, Yassin Philip wrote:
Thanks, nice procedure, quite straightforward (what
would be the
differences in "the Ubuntu way"?) But I was really hoping to be able
to automate all this, alas the menuconfig phase always require human
intervention... Is there really no way to just (de)select the options
you need, programmatically?
I don't know how to do it the Ubuntu style. They build something that
installs an "abi" file,
https://wiki.ubuntu.com/KernelTeam/BuildSystem/ABI . I didn't read this.
Btw. I don't have in mind what you need to install, to get the tools to
build a kernel. I always install build-essential and things like sthis
for my installs.
Maybe
https://help.ubuntu.com/community/Kernel/Compile
is helpful, I didn't read it myself.
Don't worry, building the Debian style is done by many experienced
Ubuntu users.
I forgot to mention something very important:
https://www.kernel.org/category/signatures.html
You not necessarily need to do this to build a kernel, but you most
likely want to do this verifying.
Regards,
Ralf
12:11 p.m.
On Fri, 4 Nov 2016 10:35:12 +0000, Yassin Philip wrote:
Is there really no way to just (de)select the options
you need,
programmatically?
There isn't, but assuming you already have a config of a generic
or lowlatency kernel with exactly the same version, you want to build
with the rt patch and if you exactly know what are the current rt
related options, you e.g. could use the sed command to edit the config
by a script. There are still pitfall. Regarding some even non-rt related
options, e.g. CONFIG_HZ_1000, it's disputable what to use or not to use.
Depending on the rt patched kernel you want to build, it might make a
difference, if you are using an AMD or Intel CPU, what options to use.
There several times were serious issues with AMD CPUs, that required
dedicated configurations. There is a reason why distros usually don't
provide realtime kernels by official repositories. It's a kernel that
requires fine tuning, it's not a kernel off the rack.
12:44 p.m.
On 04/11/2016 11:11, Ralf Mardorf wrote:
On Fri, 4 Nov 2016 10:35:12 +0000, Yassin Philip
wrote:
Wow... And I'm not
even sure that it's worth :/ I guess I'll stick to my
"sudo apt install linux-lowlatency" nobrainer. One has to admit it's
easier, it even puts itself as default in grub, and stays up-to-date :|
By the way, does the rtirq-init IRQ balancing script work with this kind
of kernel? It seems to launch OK, but given its description "startup
script for realtime-preempt enabled kernels" does it do anything good on
a lowlatency system?
Does anybody here use lowlatency kernels, and do they come with special
usage tips and recommendations? Thanks a lot anyway, Ralf;
Phil
Is there really no way to just (de)select the
options you need,
programmatically?
There isn't, but assuming you already have a config of a
generic
or lowlatency kernel with exactly the same version, you want to build
with the rt patch and if you exactly know what are the current rt
related options, you e.g. could use the sed command to edit the config
by a script. There are still pitfall. Regarding some even non-rt related
options, e.g. CONFIG_HZ_1000, it's disputable what to use or not to use.
Depending on the rt patched kernel you want to build, it might make a
difference, if you are using an AMD or Intel CPU, what options to use.
There several times were serious issues with AMD CPUs, that required
dedicated configurations. There is a reason why distros usually don't
provide realtime kernels by official repositories. It's a kernel that
requires fine tuning, it's not a kernel off the rack. _______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
Yassin Philip - New album out NOW
http://yassinphilip.bitbucket.org
1:20 p.m.
On Fri, 4 Nov 2016 11:44:47 +0000, Yassin Philip wrote:
By the way, does the rtirq-init IRQ balancing script
work with this kind of kernel? It seems to launch OK, but given its
description "startup script for realtime-preempt enabled kernels" does
it do anything good on a lowlatency system?
Does anybody here use lowlatency kernels, and do they come with
special usage tips and recommendations?
The lowlatency kernel is a 'normal' kernel, just with 'threadirqs'
enabled. If you use the boot option 'threadirqs', then a 'normal'
kernel is a 'loalatency' kernel, too. The Ubuntu maintainers might
change some options that differ between a so called 'lowlatency' and
'general' kernel, e.g. CONFIG_HZ=1000 instead of CONFIG_HZ=250, or
CONFIG_PREEMPT=y instead of CONFIG_PREEMPT_VOLUNTARY=y. However, both
are vanilla kernels, perhaps with Ubuntu patches, that wouldn't make any
sense at all.
The PREEMPT options make a difference, but HZ=1000 unlikely makes a
difference at all. MIDI software timer anyway should be HR timer and I
don't know if it makes a difference for audio.
FWIW NO_HZ settings are the same for 'general' and 'lowlatency' kernels.
Yes, rtirq does work for rt patched kernels, for 'normal' kernels, such
as the lowlatency kernel, if 'threadirqs' is used. IOW for 'lowlatency'
by default and for 'general' if you add the boot option 'threadirqs' to
grub.cfg or somewhere in the config files for the config file. I edit
grub.cfg directly.
Regards,
Ralf
2:57 p.m.
On Fri, November 4, 2016 7:20 am, Ralf Mardorf wrote:
Yes, rtirq does work for rt patched kernels, for
'normal' kernels, such
as the lowlatency kernel, if 'threadirqs' is used. IOW for 'lowlatency'
by default and for 'general' if you add the boot option 'threadirqs' to
grub.cfg or somewhere in the config files for the config file.
Check the documentation for the version of kernel you are using, I think
the threadirqs behavior became the default at some point if the PREEMPT
config option was selected, but I do not remember which version. In other
words, new kernel versions may not require to add threadirqs to grub.cfg,
check the kernel command line documentation first.
--
Chris Caudle
3:19 p.m.
On Fri, 4 Nov 2016, Yassin Philip wrote:
Wow... And I'm not even sure that it's worth
:/ I guess I'll stick to my
"sudo apt install linux-lowlatency" nobrainer. One has to admit it's
easier,
it even puts itself as default in grub, and stays up-to-date :| By the way,
Glad you like it. The grub hack (really hack is the only word) is mine
assuming you use Studio. Changing the grub hack to work with RT kernels
would be quite easy.
does the rtirq-init IRQ balancing script work with
this kind of kernel? It
Yes rtirq works with low latency. As the work on RT went on most of the RT
patches have become mainline. The low latency includes all the RT stuff in
mainline kernel. There are some people who do actually need RT so I will
not suggest "nobody needs RT for Audio" as RT does seem to help with some
kinds of difficult hardware and/or high cpu load uses. Even with RT there
is more than one kind. Kernels are one of the most distro agnostic bits of
code around. Dropping an RT kernel for some place else is likely to
work... and if not grub gives the choice of booting from something else so
you can remove it :)
Does anybody here use lowlatency kernels, and do they
come with special usage
tips and recommendations? Thanks a lot anyway, Ralf;
The use of low latecny kernels in audio is quite common. Taking care of
everything else first (own irq, good USB port for USB cards, PCI audio in
the first place, etc) can allow the use of 1 or 2 ms latency with no
xruns. As CPU use increases with the use of more synths towards max DSP it
may be possible to get just a bit more cpu use with RT.
--
Len Ovens
www.ovenwerks.net
4:30 p.m.
On 11/04/2016 11:44 AM, Yassin Philip wrote:
On 04/11/2016 11:11, Ralf Mardorf wrote:
> On Fri, 4 Nov 2016 10:35:12 +0000, Yassin Philip wrote:
>> Is there really no way to just (de)select the options you need,
>> programmatically?
let me tell ya what do as a routine **before** every and any `make
oldconfig`, just to make sure fulcrum and interesting rt-kernel params
are stuck in place:
echo "CONFIG_PREEMPT_RT_FULL=y" >> .config
echo "CONFIG_HZ_1000=y" >> .config
hth.
cheers
--
rncbc aka. Rui Nuno Capela
10:24 p.m.
On Fri, Nov 4, 2016 at 3:30 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
On 11/04/2016 11:44 AM, Yassin Philip wrote:
surely a tickless kernel is much better on almost any vaguely modern
hardware?
On 04/11/2016 11:11, Ralf Mardorf wrote:
> On Fri, 4 Nov 2016 10:35:12 +0000, Yassin Philip wrote:
>> Is there really no way to just (de)select the options you need,
>> programmatically?
let me tell ya what do as a routine **before** every and any `make
oldconfig`, just to make sure fulcrum and interesting rt-kernel params
are stuck in place:
echo "CONFIG_PREEMPT_RT_FULL=y" >> .config
echo "CONFIG_HZ_1000=y" >> .config
10:51 p.m.
On 11/04/2016 09:24 PM, Paul Davis wrote:
On Fri, Nov 4, 2016 at 3:30 PM, Rui Nuno Capela <rncbc(a)rncbc.org
<mailto:rncbc@rncbc.org>> wrote:
echo "CONFIG_PREEMPT_RT_FULL=y" >> .config
echo "CONFIG_HZ_1000=y" >> .config
surely a tickless kernel is much better on almost any vaguely modern
hardware?
none of the above abstains you from a tickless kernel
CONFIG_NO_HZ and CONFIG_NO_HZ_IDLE are untouched, as far as `make
oldconfig` goes
cheers
--
rncbc aka. Rui Nuno Capela
5 Nov
5 Nov
1:45 a.m.
i'm just wondering why you'd bother to set HZ when the preferred
configuration is NO_HZ .. ?
On Fri, Nov 4, 2016 at 9:51 PM, Rui Nuno Capela <rncbc(a)rncbc.org> wrote:
On 11/04/2016 09:24 PM, Paul Davis wrote:
On Fri, Nov 4, 2016 at 3:30 PM, Rui Nuno Capela <rncbc(a)rncbc.org
<mailto:rncbc@rncbc.org>> wrote:
echo "CONFIG_PREEMPT_RT_FULL=y" >> .config
echo "CONFIG_HZ_1000=y" >> .config
surely a tickless kernel is much better on almost any vaguely modern
hardware?
none of the above abstains you from a tickless kernel
CONFIG_NO_HZ and CONFIG_NO_HZ_IDLE are untouched, as far as `make
oldconfig` goes
cheers
--
rncbc aka. Rui Nuno Capela
5 a.m.
On Fri, 4 Nov 2016 08:56:42 -0500, Chris Caudle wrote:
Which btw. is the default for the Ubuntu kernels and the Arch rt
kernels, I guess I didn't mention this clearly enough. So coping a
config automatically enables it.
However, different opinions are the reason that I didn't recommended RT
configurations. Let alone all the issues, that e.g. the frequency
scaling governor and a few other settings could lock AMD CPUs for some
Linux version with an rt patch.
Regards,
Ralf
Check the documentation for the version of kernel you
are using, I
think the threadirqs behavior became the default at some point if the
PREEMPT config option was selected, but I do not remember which
version. In other words, new kernel versions may not require to add
threadirqs to grub.cfg, check the kernel command line documentation
first.
If threadirqs should be required, the output of rtirq status would look
like this:
[rocketmouse@archlinux ~]$ rtirq status
PID CLS RTPRIO NI PRI %CPU STAT COMMAND
3 TS - 0 19 0.0 S ksoftirqd/0
17 TS - 0 19 0.0 S ksoftirqd/1
[rocketmouse@archlinux ~]$
IOW simply run (usually /path/to/)rtirq status , assuming
threadirqs shouldn't be required, the OP should see a long list with
priorities, including the sound card. No need to read a documentation.
On Sat, 5 Nov 2016 00:45:43 +0000, Paul Davis wrote:
On Fri, Nov 4, 2016 at 9:51 PM, Rui Nuno Capela wrote:
> On 11/04/2016 09:24 PM, Paul Davis wrote:
> > On Fri, Nov 4, 2016 at 3:30 PM, Rui Nuno Capela wrote:
> > echo "CONFIG_PREEMPT_RT_FULL=y" >> .config
> > echo "CONFIG_HZ_1000=y" >> .config
> >
> > surely a tickless kernel is much better on almost any vaguely
> > modern hardware?
Apart from this, for MIDI we usually use HR timer ;).
none of the
above abstains you from a tickless kernel
CONFIG_NO_HZ and CONFIG_NO_HZ_IDLE are untouched, as far as `make
oldconfig` goes
i'm just wondering why you'd bother to set HZ when the
preferred
configuration is NO_HZ .. ?
11:02 a.m.
On 11/05/2016 12:45 AM, Paul Davis wrote:
On Fri, Nov 4, 2016 at 9:51 PM, Rui Nuno Capela wrote:
well, the so called "tickless" option is about omitting kernel
scheduling clock ticks on *idle* cpus. the sched clock will still tick
to the HZ setting on regular basis on non-idle situations.
setting the HZ=1000 is mostly desirable for the default ALSA MIDI system
timers to have a better resolution than the Linus' default (HZ=250).
byee
--
rncbc aka. Rui Nuno Capela
echo "CONFIG_PREEMPT_RT_FULL=y" >> .config
echo "CONFIG_HZ_1000=y" >> .config
On 11/04/2016 09:24 PM, Paul Davis wrote:
>
> surely a tickless kernel is much better on almost any vaguelymodern hardware?
>
> On Fri, Nov 4, 2016 at 3:30 PM, Rui Nuno Capela wrote:
>>
>> none of the above abstains you from a tickless kernel
>>
>> CONFIG_NO_HZ and CONFIG_NO_HZ_IDLE are untouched, as far as`make oldconfig`
goes
>>
i'm just wondering why you'd bother to set HZ when the preferred configuration is
NO_HZ .. ?
11:33 a.m.
On 11/05/2016 10:26 AM, Jeremy Jongepier wrote:
that's true, iif you also have CONFIG_SND_HRTIMER and
CONFIG_SND_SEQ_HRTIMER_DEFAULT set.
byee
--
rncbc aka. Rui Nuno Capela
setting the
HZ=1000 is mostly desirable for the default ALSA MIDI system
timers to have a better resolution than the Linus' default (HZ=250).
I thought nowadays ALSA used the snd_hrtimer module which has a way
higher resolution than 1000HZ.
2941
days inactive
2942
days old
linux-audio-user@lists.linuxaudio.org
16 comments
7 participants
participants (7)
-
Chris Caudle -
Jeremy Jongepier -
Len Ovens -
Paul Davis -
Ralf Mardorf -
Rui Nuno Capela -
Yassin Philip