Re: Maximum frequency of re-scheduling (minimum time quantum) que stio n

[Con Kolivas <kernel@kolivas.org>]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

Elladan wrote:
> On Wed, Jul 07, 2004 at 03:59:01AM -0400, Povolotsky, Alexander wrote:
> 
>>Thanks to both of you for answering !
>>
>>
>>>The catch here is, without the preemptable kernel option, the kernel
>>>can't preempt itself, so if the first process was doing something in the
>>>kernel, there'd be a delay.  Even with the option, it can't preempt
>>>itself inside of a critical section, so there will still be a (shorter)
>>>delay.
>>
>>Yes, I am aware, - thanks to the previous answer (not included here), about
>>this Linux 2.6
>>configurable "preemptable kernel" option and was assuming it is configured
>>and in effect.
> 
> 
> Note that the preemptable kernel gives you no guarantee of latency,
> though it does reduce the average latency.  A different patch was
> constructed in the 2.4 era which attempted to provide guaranteed latency
> through a different approach (effectively, having all long-running
> operations yield).

2.6 is not that different from the lowlat patches. Note that many of 
these lock breaking points and conditional rescheduling were actually 
put into 2.5 development so are in 2.6 mainline.

Con

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]