Messages in this thread | | | Date | Fri, 13 Jun 2003 23:03:55 -0700 | From | Andrew Morton <> | Subject | Re: lowlatency fixes needed in 2.4 and 2.5 |
| |
Andrea Arcangeli <andrea@suse.de> wrote: > > On Fri, Jun 13, 2003 at 08:03:46PM +0000, Robert Love wrote: > > On Fri, 2003-06-13 at 18:56, Ramón Rey Vicente????ey Vicente wrote: > > > > > And, what's about the low_latency/preemptible patches? > > > > We did all that and more for 2.5. > > the lowlatency patches are a must for 2.4, let's put them under the > security bugfix headline and maybe they will get merged eventually ;).
Agree.
> 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; > > repeat_lock_task: > local_irq_save(*flags); > 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 > something?
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.
yup.
- 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/
| |