lkml.org 
[lkml]   [2002]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 2.4.17 vs 2.2.19 vs rml new VM
Well it is possible that with the several patches
you mention that I might see results similar to
what I now see with the low-latency patch.

However -

The preempt patch does NOT play well with the
tux webserver, which I am using. So, preempt is
not an option for me until and unless it is cleaned
up to allow cooperation with tux.

tux and low-latency get along just fine.

cu

jjs

Dieter Nützel wrote:

>On Tuesday, 2. January 2002 20:50, Alan cox wrote:
>
>>>I find the low latency patch makes a noticeable
>>>difference in e.g. q3a and rtcw - OTOH I have
>>>not been able to discern any tangible difference
>>>from the stock kernel when using -preempt.
>>>
>>The measurements I've seen put lowlatency ahead of pre-empt in quality
>>of results. Since low latency fixes some of the locked latencies it might
>>be interesting for someone with time to benchmark
>>
>> vanilla
>> low latency
>> pre-empt
>> both together
>>
>
>Don't forget that you have to use preempt-kernel-rml + lock-break-rml to
>achieve the same (more) than the latency patch.
>
>Taken from Robert's page and running it for some weeks, now.
>
>[-]
>Lock breaking for the Preemptible Kernel
>lock-break-rml-2.4.15-1
>lock-break-rml-2.4.16-3
>lock-break-rml-2.4.17-2
>lock-break-rml-2.4.18-pre1-1
>README
>ChangeLog
>With the preemptible kernel, the need for explicit scheduling points, like in
>the low-latency patches, are no more. However, since we can not preempt while
>locks are held, we can take a similar model as low-latency and "break" (drop
>and immediately reacquire) locks to improve system response. The trick is
>finding when and where we can safely break the locks (periods of quiescence)
>and how to safely recover. The majority of the lock breaking is in the VM and
>VFS code. This patch is for users with strong system response requirements
>affected by the worst-case latencies caused by long-held locks.
>[-]
>
>Regards,
> Dieter
>


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:15    [W:0.085 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site