Hi there,
here's a newbie question:
is it UNadvisable to apply both preempt-kernel-rml and low-latency patches
over a 2.4.18 kernel?
thanx in advance
--
wwp
wwp wrote:
> Hi there,
>
> here's a newbie question:
> is it UNadvisable to apply both preempt-kernel-rml and low-latency patches
> over a 2.4.18 kernel?
In short: no ;-)
Try 2.4.18-rc4-jam2 for example. It should apply against 2.4.18 final, too.
Regards,
Dieter
On 20020226 Dieter N?tzel wrote:
>wwp wrote:
>> Hi there,
>>
>> here's a newbie question:
>> is it UNadvisable to apply both preempt-kernel-rml and low-latency patches
>> over a 2.4.18 kernel?
>
>In short: no ;-)
>
>Try 2.4.18-rc4-jam2 for example. It should apply against 2.4.18 final, too.
>
Correction: jam2 is O(1)-multi-queue scheduler + low-latency, no
preeemt there.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-jam1 #1 SMP Tue Feb 26 00:06:55 CET 2002 i686
Hi J.A.,
On Tue, 26 Feb 2002 23:55:10 +0100 "J.A. Magallon" <[email protected]> wrote:
[snip]
> >Try 2.4.18-rc4-jam2 for example. It should apply against 2.4.18 final, too.
> >
>
> Correction: jam2 is O(1)-multi-queue scheduler + low-latency, no
> preeemt there.
Won't 2.4.18-jam1 better?
Regards,
--
wwp
On 20020227 wwp wrote:
>Hi J.A.,
>
>
>On Tue, 26 Feb 2002 23:55:10 +0100 "J.A. Magallon" <[email protected]> wrote:
>
>[snip]
>> >Try 2.4.18-rc4-jam2 for example. It should apply against 2.4.18 final, too.
>> >
>>
>> Correction: jam2 is O(1)-multi-queue scheduler + low-latency, no
>> preeemt there.
>
>Won't 2.4.18-jam1 better?
>
Same patches over a more recent kernel.
Even 2.4.18-jam1 includes the fix for the personality problem.
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.18-jam1 #1 SMP Tue Feb 26 00:06:55 CET 2002 i686
On Dienstag, 26. Februar 2002 23:55:23, J.A. Magallon wrote:
> On 20020226 Dieter N?tzel wrote:
> >wwp wrote:
> >> Hi there,
> >>
> >> here's a newbie question:
> >> is it UNadvisable to apply both preempt-kernel-rml and low-latency
> >> patches over a 2.4.18 kernel?
> >
> >In short: no ;-)
> >
> >Try 2.4.18-rc4-jam2 for example. It should apply against 2.4.18 final,
> > too.
>
> Correction: jam2 is O(1)-multi-queue scheduler + low-latency, no
> preeemt there.
I put it on top as always...;-)
Did that before all by hand, now you have set the starting point.
Regards,
Dieter
BTW I will use 2.4.18-jam1.
wwp wrote:
>
> Hi there,
>
> here's a newbie question:
> is it UNadvisable to apply both preempt-kernel-rml and low-latency patches
> over a 2.4.18 kernel?
>
> thanx in advance
>
> --
I believe that the preempt kernel patch or one related to it does the
low-latency stuff in a more economical way, i.e. takes advantage of the
preemption code to implement the low-latency stuff. See the lock-break
patch that rml has. It should be right next to the preempt patch.
--
George [email protected]
High-res-timers: http://sourceforge.net/projects/high-res-timers/
Real time sched: http://sourceforge.net/projects/rtsched/
george anzinger wrote:
>
> wwp wrote:
> >
> > Hi there,
> >
> > here's a newbie question:
> > is it UNadvisable to apply both preempt-kernel-rml and low-latency patches
> > over a 2.4.18 kernel?
> >
> > thanx in advance
> >
> > --
> I believe that the preempt kernel patch or one related to it does the
> low-latency stuff in a more economical way,
Sigh. Not to single you out, George - I see abject misunderstanding
and misinformation about this sort of thing all over the place.
So let's make some statements:
- preemption is more expensive that explicit scheduling points. Always
was, always shall be.
- Anyone who has performed measurements knows that preemption is
ineffective. Worst-case latencies are still up to 100 milliseconds.
- preemptability is a *basis* for getting a maintainable low-latency
kernel. And that's the reason why I support its merge into 2.5. Same
with Ingo, I expect.
But there's a lot of icky stuff to be done yet to make it effective.
> i.e. takes advantage of the
> preemption code to implement the low-latency stuff. See the lock-break
> patch that rml has. It should be right next to the preempt patch.
lock-break is missing the cross-SMP reschedule hack, so on SMP it'll
still have very high worst-case latencies. If all the other parts
of the low-latency patch were included then preempt+lock-break should
give better results than low-latency.
-
Hi all,
Okay, I would like to thank everyone who has answered my newbie
question! It has helped, making the differences between lo-latency
and preempt patches more clear to me :-)
Regards
--
wwp