21 Dec
2005
21 Dec
'05
6:24 p.m.
On Wed, 21 Dec 2005 15:06:18 -0600
Josh Lawrence <hardbop200(a)gmail.com> wrote:
Not quite. In a vanilla 2.6.14 kernel you can select from the following
preemption models:
( ) No Forced Preemption (Server)
( ) Voluntary Kernel Preemption (Desktop)
(X) Preemptible Kernel (Low-Latency Desktop)
So, if you use a vanilla kernel make sure the last entry is activated
(i.e. via make menuconfig)
In a kernel patched with the realtime preemption patches (-rt) you get
an additional entry:
(X) Complete Preemption (Real-Time)
This also introduces the prioritization of irq handler threads i talked
about. But before even considering using a -rt kernel, first test a
normal 2.6.14 vanilla kernel with "Preemptible Kernel (Low-Latency
Desktop)" enabled and of course,
[*] Preempt The Big Kernel Lock
too.
I see, this is exactly the kind of thing I was looking
for, and now
that I think about it, it makes total sense. Let me see if I
understand it: rtlimits allows a normal user to preempt, but you must
enable the preemption option in the kernel config in the first place
for it to do any good. Is that it?
rtlimits/realtime_lsm allows a normal user to run tasks with SCHED_FIFO
scheduling. This is a scheduling class that gets the CPU before any
normal SCHED_OTHER task and is statically prioritized (as opposed to
SCHED_OTHER where you can set a "nice" value, but the real priority is
determined based on some heuristics depending on resource usage of the
task). See i.e.
http://ccrma.stanford.edu/planetccrma/man/man2/sched_setscheduler.2.html
for a more detailed description.
It is quite ok
for most uses, especially when not going for ultra low
latencies (like 8 or 16 frames). Make sure you use the "(X) Preemptible
Kernel (Low-Latency Desktop)" setting though when building a vanilla
kernel (or make sure your distro builds it this way if you use a distro
provided kernel; check i.e. /proc/config.gz and/or write a mail to the
appropriate ML/maintainer).
Again, this is apparently the part that must be "enabled" to see the
full benefits of using rtlimits, correct? Once I've enabled this
option (Preemptible Kernel), do I then have what you are referring to
as a -rt kernel? I don't think that I am the type of user that
needs that kind of low
latency, I just need enough to do my basic home recordings.
I think, in light of this, I might install DeMudi on my seperate
partition; it might avoid all of this kernel business very easily. I
still hate that I don't know how to do things myself, so any further
comment is welcome.
Yeah, just for some hd recording and no i.e. using your computer as live
effects rack, i.e. for guitar or for softsynths, large periodsizes are
usually fine (large = around 1024 frames). For softsynths i'd recommend
a periodsize smaller than or equal to 128 frames. Dunno how well that
works on vanilla kernels. Especially if you need _rock solid_
performance (i.e. no dropouts at all).
Flo
--
Palimm Palimm!
http://tapas.affenbande.org