25 Apr
2008
25 Apr
'08
12:27 p.m.
Hi guys, perhaps I'm missing the point here but the kernels linked in
a later post here:
http://packages.ubuntu.com/gutsy/linux-image-2.6.22-14-rt
http://packages.ubuntu.com/hardy/linux-image-2.6.24-16-rt
are both patched w/ the rt patchset allowing full preemption. I am
aware you can get realltime as root though its a _bad_ idea. patches
are not available for the 25 series yet. Can someone sort this out?
25 Apr
25 Apr
1:23 p.m.
New subject: realtime problem on 2.6.25
On Fri, 2008-04-25 at 07:27 -0700, Ben Tartsa wrote:
Hi guys, perhaps I'm missing the point here but
the kernels linked in
a later post here:
http://packages.ubuntu.com/gutsy/linux-image-2.6.22-14-rt
http://packages.ubuntu.com/hardy/linux-image-2.6.24-16-rt
are both patched w/ the rt patchset allowing full preemption. I am
aware you can get realltime as root though its a _bad_ idea. patches
are not available for the 25 series yet. Can someone sort this out?
it is time to once again make clear some fundamentals.
* the ability to obtain SCHED_FIFO scheduling and use mlock(2) are
*COMPLETELY* separate from whether or not a kernel has been
built with Ingo's RT patches
and the corollary:
* a kernel built with Ingo's RT patches is not required to and does
not by itself ensure that a non-root user can use SCHED_FIFO
and mlock(2)
Ingo's RT patches simply make the performance of a system using
SCHED_FIFO-scheduled threads *better*. They have *absolutely nothing* to
do with whether or not a normal user can successfully execute a program
that wants to use SCHED_FIFO. that is determined by other non-kernel
elements of your system (which parts varies by distro, but primarily PAM
on most current distros).
--p
2:14 p.m.
New subject: realtime problem on 2.6.25
On Fri, 2008-04-25 at 11:23 -0400, Paul Davis wrote:
Ingo's RT patches simply make the performance of a
system using
SCHED_FIFO-scheduled threads *better*. They have *absolutely nothing* to
do with whether or not a normal user can successfully execute a program
that wants to use SCHED_FIFO. that is determined by other non-kernel
elements of your system (which parts varies by distro, but primarily PAM
on most current distros).
If I may differ, it *sometimes* makes the performance of systems using
SCHED_FIFO-scheduled threads better.
When I tried it, my system fell to pieces, and I was unable to figure
out how to tune it back to working in a reasonable amount of time (say
40 hours). So I've been sticking with SCHED_FIFO without Ingo's RT
patches. At least this way things basically work with enough buffering.
Although somehow regular priority threads (and processes) still manage
to interfere with my SCHED_FIFO threads.
Maybe I should bring this up on the dev list again.
2:27 p.m.
New subject: realtime problem on 2.6.25
On Fri, 2008-04-25 at 12:14 -0400, Joshua D. Boyd wrote:
When I tried it, my system fell to pieces, and I was
unable to figure
out how to tune it back to working in a reasonable amount of time (say
40 hours). So I've been sticking with SCHED_FIFO without Ingo's RT
patches. At least this way things basically work with enough buffering.
Although somehow regular priority threads (and processes) still manage
to interfere with my SCHED_FIFO threads.
They can do that if they use syscalls that run for a long time in the
kernel without getting pre-empted. The whole point of the RT patch is to
make those kernel code paths shorter.
--ll
6057
days inactive
6057
days old
linux-audio-user@lists.linuxaudio.org
3 comments
4 participants
participants (4)
-
Ben Tartsa -
Joshua D. Boyd -
Lars Luthman -
Paul Davis