Re: [patch] Real-Time Preemption, -VP-2.6.9-rc4-mm1-U1

[Ingo Molnar <mingo@elte.hu>]

* Mark_H_Johnson@Raytheon.com <Mark_H_Johnson@Raytheon.com> wrote:

> Not sure if I can bring this up to multi user yet. Some initial testing
> in single user mode indicates problems when I turn on networking. See
> the attached messages from /var/log/messages to see the kinds of problems
> I am having. The key ones appear after doing
>   ./S10network start
> as part of single stepping the init sequence. I stopped at this point
> to make sure I had a good record of the messages.

could you try to disable SELINUX? It seems it's not fully safe yet.

> A side question - if
>   CONFIG_PREEMPT_REALTIME=y
> you say that IRQ's must be threaded, is this going to be "permanent" and
> if so - why?

in a fully preemptible model all execution must be 'sequential', because
irq threads themselves can schedule too and could be preempted too. The
only way to make 'direct' interrupts possible again would be to disable
interrupts in _all_ non-preemptible sections, which would be quite some
work.

Another reason for the 'linearization' of as much execution as possible
is that such direct interrupts couldnt be preempted (or else you could
reenter them) which is impossible because all locks are mutexes.

a third reason is that nesting 'blocks' any underlying context. So if
task A is interrupted by irq X and schedules away (lets assume this is
safe) - nobody could unwind 'task A' - irq X blocks it until it finishes
execution. With linearlized contexts 'task A' could reschedule on
another CPU - or could get its priority raised with time if an RT
deadline is approaching, etc. It's much more flexible to have everything
flattened out.

this comes at a performance cost - but basically if you implement all
the properties one would expect form such an approach you'd end up with
a completely different irq scheduler - there's no point in that. Best is
to 'merge' all contexts, hardirqs and softirqs into the normal task
concept.

> I would prefer to not use threaded IRQ's if possible due to lower CPU
> overhead [see previous email describing results...] and some problems
> I see with setting priorities on those IRQ's (relative to real time
> tasks).

the overhead we can try to optimize later on. What problems do you see
with setting priorities on those IRQs?

	Ingo