lkml.org 
[lkml]   [2006]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] Avoid moving tasks when a schedule can be made.

* 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
-
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: 2006-02-01 15:41    [W:0.079 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site