Re: lowlatency fixes needed in 2.4 and 2.5

Andrew Morton (
Fri, 13 Jun 2003 23:03:55 -0700

Andrea Arcangeli <> 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 ;).


> 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at