Re: [PATCH] Avoid moving tasks when a schedule can be made.

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> What I am talking about is when you want a task to have the highest 
> possible scheduling priority and you'd like to guarantee that it is 
> not interrupted for more than Xus, including scheduling latency.

this is not a big issue in practice, because it's very hard to saturate 
current x86 systems running the -rt kernel with pure IRQ load. The APIC 
messages all have a natural latency, which serves as a throttler.

[ Pretty much the only way i know to lock up a box via hardirq load is
  to misprogram the local APIC timer IRQ. (but we have protection
  against that in the HRT code, and the same is not possible via
  external interrupts.) ]

in case this becomes a problem (on some other platforms) we have a 
solution for it: interrupt prioritiziation. We didnt want to complicate 
things with this in the current IRQ preemption model, but it's all 
pretty straightforward to do.

> Now in your kernel you can measure a single long interrupt time, but 
> if you "break" that latency by splitting it into two interrupts, the 
> end result will be the same if not worse due to decreased efficiency.

there really is a maximum rate of interrupts you can inject, which has 
an effect of slowing down the CPU, which has a linear effect on the 
worst-case latency - but not not some other drastic effect.

> >not really - isolcpus is useful for certain problems, but it is not 
> >generic as it puts heavy constraints on usability and resource 
> >utilization. We have really, really good latencies on SMP too in the -rt 
> >kernel, with _arbitrary_ SCHED_OTHER workloads. Rwsems and rwlocks are 
> >not an issue, pretty much the only issue is the scheduler's 
> >load-balancing.
> 
> Then it is a fine hack for the RT kernel (or at least an improved, 
> batched version of the patch). No arguments from me.

no, it is also fine for the mainline scheduler, as long as the patch is 
clean and does the obviously right thing [which the current patch doesnt 
offer]. A 1+ msec latency with irqs off is nothing to sniff at. Trying 
to argue that 'you can get the same by using rwsems so why should we 
bother' is pretty lame: rwsems are rare and arguably broken in behavior, 
and i'd not say the same about the scheduler (just yet :-).

	Ingo