xterm scrolling speed - scheduling weirdness in 2.6 ?!
Hi...
I notice a severe speed regression with 2.6 and working in e.g. xterm on X11 (no framebuffer device in use). It is all about scrolling speed. I used to type e.g. just dmesg in a fullscreen xterm (or MGT) in 2.4 and the whole output was there lightning fast, i.e.
in 2.4:
=======
time dmesg
real 0m0.096s user 0m0.007s sys 0m0.005s
in 2.6 (first run)
======
time dmesg
[...]
real 0m3.054s user 0m0.008s sys 0m0.008s
in 2.6 (second run)
===================
dmesg >d
time cat d
real 0m0.096s
user 0m0.002s
sys 0m0.005s
in 2.6 (third run)
==================
time dmesg
real 0m0.095s user 0m0.007s sys 0m0.004s
So it is like 30 times slower on 2.6. when running for the first time... this also happens if I do e.g. find ./ and watch the output pass by...
This is without preemption on powerpc...
Anyone else with that problem - ideas of the cause ?
Soeren.
Hi !
Quoted 6 lines · Soeren Sonnenburg
So it is like 30 times slower on 2.6. when running for the first time... this also happens if I do e.g. find ./ and watch the output pass by...
This is without preemption on powerpc...
Anyone else with that problem - ideas of the cause ?
Yes, already reported a while ago. I was having this problem with ls in large directories where it sometimes took more than 10 seconds to scroll. It is clearly a scheduler problem, but most people don't seem concerned by this one since the most important to their ears is that xmms should not skip during make -j $UINT_MAX :-/ It's a bit of a shame since other than that, it seems stable enough for daily use on a desktop, but this problem is too much annoying for me to definitely switch to 2.6. I wanted to give a try to Nick's scheduler, but didn't have time yet.
Regards,
Willy
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Willy" == Willy Tarreau <[email protected]> writes:
Willy> Hi ! On Sat, Jan 03, 2004 at 07:52:36PM +0100, Soeren
Quoted 7 lines · Willy> Sonnenburg wrote:
Quoted 7 lines
So it is like 30 times slower on 2.6. when running for the first time... this also happens if I do e.g. find ./ and watch the output pass by...
This is without preemption on powerpc...
Anyone else with that problem - ideas of the cause ?
I see a very similar problem ... seems like a process doing disc I.O isn't being woken up fast enough after the I/O completes.
For some processes, allowing interrupts back on (hdparm -u1) helps; for others, switching to the deadline elevator helps; neither are complete solutions.
PeterC
Hi Peter,
Quoted 6 lines · Peter Chubb
Quoted 6 lines
Quoted 6 lines
So it is like 30 times slower on 2.6. when running for the first time... this also happens if I do e.g. find ./ and watch the output pass by...
This is without preemption on powerpc...
Quoted 8 lines
Quoted 1 line
Quoted 1 line
Anyone else with that problem - ideas of the cause ?
I see a very similar problem ... seems like a process doing disc I.O isn't being woken up fast enough after the I/O completes.
For some processes, allowing interrupts back on (hdparm -u1) helps; for others, switching to the deadline elevator helps; neither are complete solutions.
This is not I/O related since the problem happens even with simple programs such as dmesg and seq.
Cheers,
willy
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Quoted 1 line
"Willy" == Willy TARREAU <[email protected]> writes:
So it is like 30 times slower on 2.6. when running for the first time... this also happens if I do e.g. find ./ and watch the output pass by...
For some processes, allowing interrupts back on (hdparm -u1) helps; for others, switching to the deadline elevator helps; neither are complete solutions.
Willy> This is not I/O related since the problem happens even with Willy> simple programs such as dmesg and seq.
Yes ... the first time you run a program it's fetched from disc and shows a significant slowdown. Second and subsequent times, it runs at normal speed. At least, that's what *I'm* seeing.
Peter C