> It's not at all about lowlatency, it's about DoSing a box given enough
> pagecache and ram, tested it years ago the first time on some alpha.
It rather makes a mockery of SCHED_FIFO/SCHED_RR too.
> I'm not very exited about the -preempt stuff going on in 2.5 (this is
> code that is there since many months I know), just to make an example
> this code is micro-inefficient w/o -preempt configured:
> static inline runqueue_t *task_rq_lock(task_t *p, unsigned long *flags)
> struct runqueue *rq;
> rq = task_rq(p);
> when -preempt isn't configured you definitely want to do the
> local_irq_save _after_ the task_rq like we do in 2.4. It's absolutely
> wasteful to do the local_irq_save before the rq = task_rq.
> Sure this is very much nitpicking (don't need to flame me I already know
> you'll never measure any performance overhead in any macrobenchmark, and
> it only affects irq latency anyways), but still I'm concerned on how
> -preempt is impacting some piece of code like this in a not very visible
> way and because it micro-peanlizes kernel compiles with -preempt
> disabled. I really would prefer an #ifdef CONFIG_PREEMPT there (or a
> cleaner abstraction, possibly not specific to the scheduler), as a
> documentation factor.
Yes. I think we've been pretty successful in hiding the preempt mechanisms
inside existing infrastructure, so kernel/sched.c is a special case.
> I still think an explicit preempt-enable around the cpu intensive
> per-page copy users or checksums may be overall more worthwhile to
> provide lower mean latency than preempt as a whole.
> I had a short look and 2.5 w/o -preempt enabled is still buggy and needs
> the above fixes too. Andrew, is that right or am I overlooking
I completely agree. I want a non-preemptible kernel to not experience the
gross scheduling stalls: a few milliseconds is OK, a few hundred is not.
Preempt will always be better, and that's fine.
2.5 should be OK, although I haven't checked lately. grep around for
cond_resched(). The big pagecache and pagetable operations are addressed.
> In short I'd like to see those needed fixes included in 2.4 and
> _especially_ 2.5 ASAP.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/