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
kbd_bh->pckbd_leds->send_data->udelay
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")
kbd_bh->pckbd_leds->send_data
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
SMP?
> > - 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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Aug 07 2000 - 21:00:13 EST