Roger Larsson wrote:
>
> On Thursday 04 January 2001 09:43, ludovic fernandez wrote:
> > Daniel Phillips wrote:
> > > The key idea here is to disable preemption on spin lock and reenable on
> > > spin unlock. That's a practical idea, highly compatible with the
> > > current way of doing things. Its a fairly heavy hit on spinlock
> > > performance, but maybe the overall performance hit is small. Benchmarks
> > > are needed.
> >
> > I'm not sure the hit on spinlock is this heavy (one increment for lock
> > and one dec + test on unlock), but I completely agree (and volonteer)
> > for benchmarking.
>
> And the conditional jump is usually predicted correctly :-)
> +static inline void enable_preempt(void)
>
> +{
> + if (atomic_read(¤t->preemptable) <= 0) {
> + BUG();
> + }
> + if (atomic_read(¤t->preemptable) == 1) {
>
> This part can probably be put in a proper non inline function.
> Cache issues...
> + /*
> + * At that point a scheduling is healthy iff:
> + * - a scheduling request is pending.
> + * - the task is in running state.
> + * - this is not an interrupt context.
> + * - local interrupts are enabled.
> + */
> + if (current->need_resched == 1 &&
> + current->state == TASK_RUNNING &&
> + !in_interrupt() &&
> + local_irq_are_enabled())
> + {
> + schedule();
> + }
>
Actually the MontaVista Patch cleverly removes the tests for
in_interrupt() and local_irq_are_enabled() AND the state ==
TASK_RUNNING. In actual fact these states can be considered way points
on the system status vector. For example the interrupts off state
implies all the rest, the in_interrupt() implies not preemptable and
finally, not preemptable is one station away from fully preemptable.
TASK_RUNNING is easily solved by makeing schedule() aware that it is
being called for preemption. See the MontaVista patch for details.
ftp://ftp.mvista.com/pub/Area51/preemptible_kernel/
> + }
> + atomic_dec(¤t->preemptable);
>
> What if something happens during the schedule() that would require
> another thread...?
>
> +}
>
> I have been discussing different layout with George on Montavista
> also doing this kind of work... (different var and value range)
>
> static incline void enable_preempt(void) {
> if (--current->preempt_count) {
> smp_mb(); /* not shure if needed... */
> preempt_schedule();
> }
> }
>
> in sched.c (some smp_mb might be needed here too...)
> void preempt_schedule() {
> while (current->need_resched) {
> current->preempt->count++; /* prevent competition with IRQ code */
> if (current->need_resched)
> schedule();
> current->preempt_count--;
> }
> }
>
> > I'm not convinced a full preemptive kernel is something
> > interesting mainly due to the context switch cost (actually mmu contex
> > switch).
>
> It will NOT be fully, it will be mostly.
> You will only context switch when a higher prio thread gets runnable, two
> ways:
> 1) external intterupt waking higher prio process, same context swithes as
> when running in user code. We won't get more interrupts.
> 2) wake up due to something we do. Not that many places, mostly due to
> releasing syncronization objects (spinlocks does not count).
>
> If this still is a problem, we can select to only preemt to processes running
> RT stuff. SCHED_FIFO and SCHED_RR by letting them set need_resched to 2...
The preemption ususally just switches earlier. The switch would happen
soon anyway. That is what need_resched =1; means.
>
> > Benchmarking is a good way to get a global overview on this.
>
> Remember to benchmark with stuff that will make the positive aspects visible
> too. Playing audio (with smaller buffers), more reliably burning CD ROMs,
> less hichups while playing video [if run with higher prio...]
> Plain throuput tests won't tell the whole story!
>
> see
> http://www.gardena.net/benno/linux/audio
> http://www.linuxdj.com/latency-graph/
>
> > What about only preemptable kernel threads ?
>
> No, it won't help enough.
>
> --
> --
> Home page:
> http://www.norran.net/nra02596/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
