Re: [patch] lowlatency patch for 2.4, lowlatency-2.4.0-test6-B5

From: Andrew Morton (
Date: Fri Aug 04 2000 - 10:36:27 EST

Ingo Molnar wrote:
> > - 4-6 millisecs during X server startup. Again, not worth fixing IMO.
> i dont see this here - but i remember that such latencies were caused by
> psaux.

6 millisecs shutting down X. The sequence is


It's running from a tasklet, so in_interrupt() is returning true.

> > - The infamous psaux thing - not worth fixing (Benno says 20 millisecs)
> hm, i thought i fixed that. (see the pc_keyb.c changes) The same style of
> fixes can be used in psaux.c as well.

Ah I see. Yes, you did. But the BH-context is tripping it up.

hmm.. I just applied your patch to test6-pre2 (SMP) and I'm getting an NMI
oops at boot time ("Starting numlock")


it's stuck in the `for (;;)' loop in send_data (or maybe in
kbd_write_output_w). Problem goes away with UP. Is it designed to support

> > - I haven't tested fbdev - Pavel says it's bad.
> thats pretty unsolvable (just as the serial console latencies), the
> console layer assumes atomicity.

Yup. console can block _interrupts_ for 2 millisecs, which is much worse
than scheduling delays (network Rx overruns).

> > - conditional_reschedule() is a kludge
> well, is it your opinion that the assembly variant is still a kludge, what
> do you think? 2(4) instructions for a conditional_schedule() isnt all that
> bad.

I think conditional_reschedule() is just fine, but I'm an engineer. I'm
trying to interpret das patchmeister's statements:

   I'm not even against well-defined and well-thought-out "scheduling
   points". They are hackish, but if there is one or two of them to cover
   some specific behaviour then that's ok. Not a big deal.

I'll shut up on this and let him speak for himself.

> ...
> 80% of the places i fixed are only
> visible during moderate/heavy load.

Please, what workload are you testing against?

> ..
> how much RAM do you have? What latencies do you get if it gets even under
> minimal VM load. (which any consumer system will get under occasionally -
> otherwise you've spent too much money on RAM.)

With my patch, the latencies under VM pressure are utter crap. If, as you
say, the 60-200 msecs are by-design then sure, the VM needs scheduling
points. But I believe Andrea has an algorithmic fix in mind?

> ...
> Create a 100MB file and delete it. Repeat. Watch latencies.

That's fine with a conditional_schedule() in truncate_inode_pages.

> Allocate 100MB
> of RAM, run top, kill program. Repeat. Watch latencies.

zap_page_range() takes 1 microsecond per page. So a conditional_schedule
every 512 pages.

> Ditto usercopy.c. Both triggered
> latencies during bw_tcp over gigabit ethernet.

Ah, I see. I wasn't able to demonstrate any network-induced latency at all.

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

This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:13 EST