* Re: anticipatory scheduling questions
@ 2003-03-02 11:40 Felipe Alfaro Solana
2003-03-02 20:43 ` Andrew Morton
0 siblings, 1 reply; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-03-02 11:40 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
----- Original Message -----
From: Andrew Morton <akpm@digeo.com>
Date: Sat, 1 Mar 2003 02:40:24 -0800
To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> >
> > ----- Original Message -----
> > > Does basic 2.5.63 do the same thing? Do you have a feel
> > > for when it started happening?
> >
> > This has happened since the moment I switched from
> > 2.4 to 2.5.63-mm1.
>
> You have not actually said whether 2.5.63 base exhibits
> the same problem. From the vmstat traces it appears
> that the answer is "yes"?
Both 2.5.63 and 2.5.63-mm1 exhibit this behavior, but
can't be reproduced with 2.4.20-2.54.
> > I have retested this with 2.4.20-2.54, 2.5.63 and 2.5.63-mm1...
> > and have attached the files to this message
>
> Thanks. Note how 2.4 is consuming a few percent CPU, whereas 2.5 is
> consuming 100%. Approximately half of it system time.
It seems is not "user" or "system" time what's being consumed, it's
"iowait" Look below :-)
> It does appear that some change in 2.5 has caused evolution to go berserk
> during this operation.
I wouldn't say it's exactly Evolution what's going berserk. Doing a
"top -s1" while trying to reply to a big e-mail message, I've noticed
that "top" reports "iowait" starting at ~50%, then going up very fast
and then staying up at 90-95% all the time. This happens on 2.5.63
and 2.5.63-mm1, however, on 2.4.20-2.54 kernel, "iowait" stays all
the time exactly at "0%" and idle time remains steady at 90-95%.
These measures were taken using "top" with a delay of 1 second,
starting at the moment in which I try replying to a large e-mail
message.
> The next step please is:
>
> a) run top during the operation, work out which process is chewing all
> that CPU. Presumably it will be evolution or aspell
Well, the "top" command reveals that Evolution is taking very
little CPU usage (between 1 and 6%). Nearly all the time is
accounted under "iowait".
The other Evolution processes top at a peak sum of 5% of
CPU usage, more or less.
> b) Do it again and this time run
> strace -p $(pidof evolution) # or aspell
I think this is going to be difficult... as I said Evolution is a very
complex program and it spawns a lot of processes. When I
click the Reply, Evolution spawns two processes:
"gnome-gtkhtml-editor" and "gnome-spell-component".
I have little experience with process tracing and don't know
how to attach to those processes from the very beginning.
Attaching to the main Evolution process doesn't help: the "strace"
command dumps a lot of info when Evolution starts up, but
starts being useless at the moment I click the Reply and Evolution
spawns these two new processes to process the request.
Any ideas?
> This will tell us what it is up to.
I'm sorry I can't help much more. Can you give me more
pointers on how to nail this down?
Thanks!
Felipe Alfaro Solana
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-03-02 11:40 anticipatory scheduling questions Felipe Alfaro Solana
@ 2003-03-02 20:43 ` Andrew Morton
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2003-03-02 20:43 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: linux-kernel
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> > You have not actually said whether 2.5.63 base exhibits
> > the same problem. From the vmstat traces it appears
> > that the answer is "yes"?
>
> Both 2.5.63 and 2.5.63-mm1 exhibit this behavior, but
> can't be reproduced with 2.4.20-2.54.
By 2.54 I assume you mean 2.5.54?
> > > I have retested this with 2.4.20-2.54, 2.5.63 and 2.5.63-mm1...
> > > and have attached the files to this message
> >
> > Thanks. Note how 2.4 is consuming a few percent CPU, whereas 2.5 is
> > consuming 100%. Approximately half of it system time.
>
> It seems is not "user" or "system" time what's being consumed, it's
> "iowait" Look below :-)
Your vmstat traces were showing tons of user time as well as system
time. Please make sure that you have the latest version of procps,
from http://surriel.com/procps/ or http://procps.sourceforge.net/
> > It does appear that some change in 2.5 has caused evolution to go berserk
> > during this operation.
>
> I wouldn't say it's exactly Evolution what's going berserk. Doing a
> "top -s1" while trying to reply to a big e-mail message, I've noticed
> that "top" reports "iowait" starting at ~50%, then going up very fast
> and then staying up at 90-95% all the time. This happens on 2.5.63
> and 2.5.63-mm1, however, on 2.4.20-2.54 kernel, "iowait" stays all
> the time exactly at "0%" and idle time remains steady at 90-95%.
Well certainly the IO stream _looks_ like it is stuck in IO-wait a lot.
It is strange that this has been happening for a couple of months and seems
to only affect Felipe Solana's copy of evolution. I still can't get my copy
to spellcheck a thing. I need to wrestle with it a bit more.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
@ 2003-03-02 21:50 Felipe Alfaro Solana
0 siblings, 0 replies; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-03-02 21:50 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2184 bytes --]
----- Original Message -----
From: Andrew Morton <akpm@digeo.com>
Date: Sun, 2 Mar 2003 12:43:58 -0800
To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> > Both 2.5.63 and 2.5.63-mm1 exhibit this behavior, but
> > can't be reproduced with 2.4.20-2.54.
>
> By 2.54 I assume you mean 2.5.54?
No, I meant Red Hat's kernel 2.4.20-54. It's based on 2.4.21-pre4
with patches from Alan Cox, Arjan van den Ven and several
other people from RedHat.
> Your vmstat traces were showing tons of user time as well as system
> time. Please make sure that you have the latest version of procps,
> from http://surriel.com/procps/ or http://procps.sourceforge.net/
OK, I have downloaded procps 3.1.6 and have retested this on
both 2.4.20-2.54 (2.4), 2.5.63 (stock) and 2.5.63-mm1. I have attached
to this message "top -d1 -b" and "vmstat 1" command outputs,
compressed with bzip2 to shorten the message length. I hope they
will help in clarifying things a little. Both command were started up a
while before clicking "Reply" and a few seconds after the message
window opened up, just to let the system stabilize.
> Well certainly the IO stream _looks_ like it is stuck in IO-wait a lot.
>
> It is strange that this has been happening for a couple of months and seems
> to only affect Felipe Solana's copy of evolution. I still can't get my copy
> to spellcheck a thing. I need to wrestle with it a bit more.
A little bit more about my scenario: I'm running Red Hat Phoebe Beta 3
(what will in fact turn 8.1) with glibc-2.3.1, Evolution 1.2.2, XFree86 4.3.0
and KDE 3.1. I think Evolution has been compiled against glibc-2.3.1 and
so it will be using NPTL. As for XFree86 and KDE, I compiled them myself
and I'm sure they are using glibc-2.3.1 and NPTL.
Please, dont' hesitate in contacting me for further investigations.
Thanks!
Felipe Alfaro
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
[-- Attachment #2: top-2.4.20-2.54.bz2 --]
[-- Type: application/octet-stream, Size: 3634 bytes --]
[-- Attachment #3: top-2.5.63.bz2 --]
[-- Type: application/octet-stream, Size: 4106 bytes --]
[-- Attachment #4: top-2.5.63-mm1.bz2 --]
[-- Type: application/octet-stream, Size: 4653 bytes --]
[-- Attachment #5: vmstat-2.4.20-2.54.bz2 --]
[-- Type: application/octet-stream, Size: 442 bytes --]
[-- Attachment #6: vmstat-2.5.63.bz2 --]
[-- Type: application/octet-stream, Size: 567 bytes --]
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-03-01 11:51 ` David Lang
@ 2003-03-01 17:15 ` Alan Cox
0 siblings, 0 replies; 17+ messages in thread
From: Alan Cox @ 2003-03-01 17:15 UTC (permalink / raw)
To: David Lang; +Cc: Andrew Morton, Felipe Alfaro Solana, Linux Kernel Mailing List
On Sat, 2003-03-01 at 11:51, David Lang wrote:
> wasn't there something about Evolution having problems with the change to
> child-runs-first-on-fork logic several months ago?
There was a problem with a bug in the AF_UNIX socket layer causing evolution
to fail. I don't remember a fork based one. Its quite possible there is
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
@ 2003-03-01 14:48 Felipe Alfaro Solana
0 siblings, 0 replies; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-03-01 14:48 UTC (permalink / raw)
To: tomlins, akpm, felipe_alfaro, linux-kernel
----- Original Message -----
From: Ed Tomlinson <tomlins@cam.org>
Date: Sat, 01 Mar 2003 07:48:45 -0500
To: Andrew Morton <akpm@digeo.com>, felipe_alfaro@linuxmail.org, linux-kernel@vger.kernel.org
Subject: Re: anticipatory scheduling questions
> It might also help to know the filesystem(s) being used.
I'm using "ext2"... Pretty, old isn't it? But I get good performance with it :-)
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
[not found] ` <fa.hp882fv.1u0orj9@ifi.uio.no>
@ 2003-03-01 12:48 ` Ed Tomlinson
0 siblings, 0 replies; 17+ messages in thread
From: Ed Tomlinson @ 2003-03-01 12:48 UTC (permalink / raw)
To: Andrew Morton, felipe_alfaro, linux-kernel
Andrew Morton wrote:
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>>
>> ----- Original Message -----
>> > > It wasn't a typo... In fact, both deadline and AS give roughly the
>> > > same timings (one second up or down). But I
>> > > still don't understand why 2.5 is performing so much worse than 2.4.
>> >
>> > Me either. It's a bug.
>> >
>> > Does basic 2.5.63 do the same thing? Do you have a feel for when it
>> > started happening?
>>
>> This has happened since the moment I switched from 2.4 to 2.5.63-mm1.
>
> You have not actually said whether 2.5.63 base exhibits the same problem.
> From the vmstat traces it appears that the answer is "yes"?
>
>> > > Could a "vmstat" or "iostat" dump be interesting?
>> > 2.4 versus 2.5 would be interesting, yes.
>>
>> I have retested this with 2.4.20-2.54, 2.5.63 and 2.5.63-mm1...
>> and have attached the files to this message
>
> Thanks. Note how 2.4 is consuming a few percent CPU, whereas 2.5 is
> consuming 100%. Approximately half of it system time.
>
> It does appear that some change in 2.5 has caused evolution to go berserk
> during this operation.
>
>
>> (I think pasting them
>> here would result in wrapping, making it harder to read).
>>
>> If you need more testing or benchmarking, ask for it :-)
>
> Thanks for your patience.
>
> The next step please is:
>
> a) run top during the operation, work out which process is chewing all
> that CPU. Presumably it will be evolution or aspell
>
> b) Do it again and this time run
>
> strace -p $(pidof evolution) # or aspell
>
> This will tell us what it is up to.
It might also help to know the filesystem(s) being used.
Ed Tomlinson
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-03-01 10:40 ` Andrew Morton
@ 2003-03-01 11:51 ` David Lang
2003-03-01 17:15 ` Alan Cox
0 siblings, 1 reply; 17+ messages in thread
From: David Lang @ 2003-03-01 11:51 UTC (permalink / raw)
To: Andrew Morton; +Cc: Felipe Alfaro Solana, linux-kernel
wasn't there something about Evolution having problems with the change to
child-runs-first-on-fork logic several months ago?
David Lang
On Sat, 1 Mar 2003, Andrew Morton wrote:
> Date: Sat, 1 Mar 2003 02:40:24 -0800
> From: Andrew Morton <akpm@digeo.com>
> To: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
> Cc: linux-kernel@vger.kernel.org
> Subject: Re: anticipatory scheduling questions
>
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> >
> > ----- Original Message -----
> > > > It wasn't a typo... In fact, both deadline and AS give roughly the same
> > > > timings (one second up or down). But I
> > > > still don't understand why 2.5 is performing so much worse than 2.4.
> > >
> > > Me either. It's a bug.
> > >
> > > Does basic 2.5.63 do the same thing? Do you have a feel for when it started
> > > happening?
> >
> > This has happened since the moment I switched from 2.4 to 2.5.63-mm1.
>
> You have not actually said whether 2.5.63 base exhibits the same problem.
> From the vmstat traces it appears that the answer is "yes"?
>
> > > > Could a "vmstat" or "iostat" dump be interesting?
> > > 2.4 versus 2.5 would be interesting, yes.
> >
> > I have retested this with 2.4.20-2.54, 2.5.63 and 2.5.63-mm1...
> > and have attached the files to this message
>
> Thanks. Note how 2.4 is consuming a few percent CPU, whereas 2.5 is
> consuming 100%. Approximately half of it system time.
>
> It does appear that some change in 2.5 has caused evolution to go berserk
> during this operation.
>
>
> > (I think pasting them
> > here would result in wrapping, making it harder to read).
> >
> > If you need more testing or benchmarking, ask for it :-)
>
> Thanks for your patience.
>
> The next step please is:
>
> a) run top during the operation, work out which process is chewing all
> that CPU. Presumably it will be evolution or aspell
>
> b) Do it again and this time run
>
> strace -p $(pidof evolution) # or aspell
>
> This will tell us what it is up to.
>
>
> -
> 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/
>
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-03-01 10:25 Felipe Alfaro Solana
@ 2003-03-01 10:40 ` Andrew Morton
2003-03-01 11:51 ` David Lang
0 siblings, 1 reply; 17+ messages in thread
From: Andrew Morton @ 2003-03-01 10:40 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: linux-kernel
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> ----- Original Message -----
> > > It wasn't a typo... In fact, both deadline and AS give roughly the same
> > > timings (one second up or down). But I
> > > still don't understand why 2.5 is performing so much worse than 2.4.
> >
> > Me either. It's a bug.
> >
> > Does basic 2.5.63 do the same thing? Do you have a feel for when it started
> > happening?
>
> This has happened since the moment I switched from 2.4 to 2.5.63-mm1.
You have not actually said whether 2.5.63 base exhibits the same problem.
>From the vmstat traces it appears that the answer is "yes"?
> > > Could a "vmstat" or "iostat" dump be interesting?
> > 2.4 versus 2.5 would be interesting, yes.
>
> I have retested this with 2.4.20-2.54, 2.5.63 and 2.5.63-mm1...
> and have attached the files to this message
Thanks. Note how 2.4 is consuming a few percent CPU, whereas 2.5 is
consuming 100%. Approximately half of it system time.
It does appear that some change in 2.5 has caused evolution to go berserk
during this operation.
> (I think pasting them
> here would result in wrapping, making it harder to read).
>
> If you need more testing or benchmarking, ask for it :-)
Thanks for your patience.
The next step please is:
a) run top during the operation, work out which process is chewing all
that CPU. Presumably it will be evolution or aspell
b) Do it again and this time run
strace -p $(pidof evolution) # or aspell
This will tell us what it is up to.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
@ 2003-03-01 10:25 Felipe Alfaro Solana
2003-03-01 10:40 ` Andrew Morton
0 siblings, 1 reply; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-03-01 10:25 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 942 bytes --]
----- Original Message -----
> > It wasn't a typo... In fact, both deadline and AS give roughly the same
> > timings (one second up or down). But I
> > still don't understand why 2.5 is performing so much worse than 2.4.
>
> Me either. It's a bug.
>
> Does basic 2.5.63 do the same thing? Do you have a feel for when it started
> happening?
This has happened since the moment I switched from 2.4 to 2.5.63-mm1.
> > Could a "vmstat" or "iostat" dump be interesting?
> 2.4 versus 2.5 would be interesting, yes.
I have retested this with 2.4.20-2.54, 2.5.63 and 2.5.63-mm1...
and have attached the files to this message (I think pasting them
here would result in wrapping, making it harder to read).
If you need more testing or benchmarking, ask for it :-)
Thanks!
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
[-- Attachment #2: vmstat-2.4.20-2.54 --]
[-- Type: application/octet-stream, Size: 949 bytes --]
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 0 121008 4028 70708 0 0 705 49 187 565 20 12 67
0 1 0 0 118460 4048 71564 0 0 876 0 155 1178 38 6 56
0 1 0 0 114556 4092 72996 0 0 1372 0 210 1471 29 7 64
1 0 0 0 112504 4128 74764 0 0 1804 0 247 698 29 1 70
1 0 0 0 111016 4128 76204 0 0 1440 256 209 371 0 0 100
0 1 0 0 108076 4128 79052 0 0 2848 0 190 518 1 1 98
1 0 0 0 105004 4128 82028 0 0 2976 0 195 860 0 4 96
2 0 0 0 102028 4128 84908 0 0 2880 0 192 2184 3 4 93
3 0 0 0 99836 4128 86796 0 0 1472 0 148 9283 41 8 51
2 0 0 0 98740 4128 86872 0 0 0 256 166 2027 28 4 68
[-- Attachment #3: vmstat-2.5.63 --]
[-- Type: application/octet-stream, Size: 1659 bytes --]
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 0 117228 4240 76184 0 0 573 43 1435 413 17 8 76
0 2 0 0 116540 4252 76596 0 0 424 0 1109 694 31 4 65
4 0 0 0 111260 4280 78128 0 0 1456 0 1170 1289 82 18 0
1 0 0 0 110140 4336 78872 0 0 800 0 1069 752 92 8 0
0 1 0 0 108012 4340 80932 0 0 2064 0 1107 492 50 50 0
1 1 0 0 105596 4340 83068 0 0 2136 0 1125 555 67 33 0
1 0 0 0 104156 4340 84640 0 0 1572 0 1112 495 33 67 0
0 1 0 0 102868 4340 85940 0 0 1300 0 1114 564 50 50 0
0 1 0 0 101812 4340 87432 0 0 1492 0 1111 689 50 50 0
0 1 0 0 100636 4340 88588 0 0 1156 0 1104 821 75 25 0
0 1 1 0 99548 4340 89720 0 0 1132 696 1099 1017 50 50 0
1 1 0 0 99044 4340 90200 0 0 480 0 1075 937 60 40 0
0 1 0 0 98596 4340 90740 0 0 540 0 1086 1134 67 33 0
0 1 0 0 98148 4340 91196 0 0 456 0 1086 1327 57 43 0
3 0 0 0 97508 4340 91752 0 0 348 0 1074 2920 82 18 0
2 0 0 0 96716 4340 92004 0 0 0 124 1032 2029 29 6 65
1 0 0 0 96716 4340 92004 0 0 0 0 1127 477 1 0 99
1 0 0 0 96716 4340 92036 0 0 32 0 1017 1421 20 1 79
3 0 0 0 99476 4340 91728 0 0 4 88 1150 5771 35 16 48
[-- Attachment #4: vmstat-2.5.63-mm1 --]
[-- Type: application/octet-stream, Size: 2135 bytes --]
procs memory swap io system cpu
r b w swpd free buff cache si so bi bo in cs us sy id
0 0 0 0 122484 4148 72140 0 0 908 73 1734 702 26 12 62
3 0 0 0 120740 4164 72868 0 0 744 0 1195 1002 36 8 56
2 1 0 0 116364 4192 74056 0 0 1108 0 1140 1159 87 13 0
2 0 0 0 115412 4244 74660 0 0 656 0 1116 718 94 6 0
1 1 0 0 114964 4248 75144 0 0 488 4 1146 581 0 100 0
2 0 0 0 114404 4248 75672 0 0 528 0 1157 572 50 50 0
3 0 0 0 113956 4248 76156 0 0 484 0 1145 565 100 0 0
1 1 0 0 113396 4248 76680 0 0 524 0 1157 592 33 67 0
1 1 0 0 112948 4248 77128 0 0 448 0 1133 588 50 50 0
3 0 0 0 112580 4248 77568 0 0 440 32 1139 659 50 50 0
1 1 0 0 112076 4248 78032 0 0 464 0 1139 655 33 67 0
2 0 0 0 111684 4248 78452 0 0 420 0 1130 552 67 33 0
2 0 0 0 111236 4248 78872 0 0 420 0 1129 741 67 33 0
2 0 0 0 110788 4248 79344 0 0 472 0 1142 746 33 67 0
1 1 0 0 110092 4248 79812 0 0 468 16 1143 829 80 20 0
1 1 0 0 109588 4248 80316 0 0 504 0 1150 893 50 50 0
3 0 0 0 109140 4248 80776 0 0 460 0 1140 851 50 50 0
1 1 0 0 108748 4248 81196 0 0 420 0 1128 921 50 50 0
1 1 0 0 108356 4248 81592 0 0 396 0 1123 922 50 50 0
2 1 0 0 108132 4248 81792 0 0 200 564 1135 539 67 33 0
1 1 0 0 107908 4248 82004 0 0 212 0 1116 628 33 67 0
3 0 0 0 107548 4248 82436 0 0 432 0 1133 960 60 40 0
1 1 0 0 107100 4248 82884 0 0 448 0 1135 1484 57 43 0
4 0 0 0 106484 4248 83452 0 0 360 0 1115 1548 86 14 0
2 0 0 0 105636 4248 83712 0 0 8 0 1170 2256 41 5 54
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-02-28 23:12 Felipe Alfaro Solana
@ 2003-02-28 23:16 ` Andrew Morton
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2003-02-28 23:16 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: felipe_alfaro, linux-kernel
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> ----- Original Message -----
> From: Andrew Morton <akpm@digeo.com>
> Date: Fri, 28 Feb 2003 11:14:18 -0800
> To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
> Subject: Re: anticipatory scheduling questions
>
> > "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> > > I have done so: Evolution is a complex application with many interdependencies and is
> > > not very prone to launch diagnostic messages to the console. Anyways, I haven't seen
> > > any diagnostic message in the console. I still think there is something in the AS I/O scheduler
> > > that is not working at full read throughput. Of course I'm no expert.
> >
> > It certainly does appear that way. But you observed the same runtime
> > with the deadline scheduler. Or was that a typo?
> >
> > > > 2.4.20-2.54 -> 9s
> > > > 2.5.63-mm1 w/Deadline -> 34s
> > > > 2.5.63-mm1 w/AS -> 33s
>
> It wasn't a typo... In fact, both deadline and AS give roughly the same
> timings (one second up or down). But I
> still don't understand why 2.5 is performing so much worse than 2.4.
Me either. It's a bug.
Does basic 2.5.63 do the same thing? Do you have a feel for when it started
happening?
> Could a "vmstat" or "iostat" dump be interesting?
2.4 versus 2.5 would be interesting, yes.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
@ 2003-02-28 23:12 Felipe Alfaro Solana
2003-02-28 23:16 ` Andrew Morton
0 siblings, 1 reply; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-02-28 23:12 UTC (permalink / raw)
To: akpm, Felipe Alfaro Solana; +Cc: linux-kernel
----- Original Message -----
From: Andrew Morton <akpm@digeo.com>
Date: Fri, 28 Feb 2003 11:14:18 -0800
To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> > I have done so: Evolution is a complex application with many interdependencies and is
> > not very prone to launch diagnostic messages to the console. Anyways, I haven't seen
> > any diagnostic message in the console. I still think there is something in the AS I/O scheduler
> > that is not working at full read throughput. Of course I'm no expert.
>
> It certainly does appear that way. But you observed the same runtime
> with the deadline scheduler. Or was that a typo?
>
> > > 2.4.20-2.54 -> 9s
> > > 2.5.63-mm1 w/Deadline -> 34s
> > > 2.5.63-mm1 w/AS -> 33s
It wasn't a typo... In fact, both deadline and AS give roughly the same timings (one second up or down). But I
still don't understand why 2.5 is performing so much worse than 2.4. Could a "vmstat" or "iostat" dump be
interesting?
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-02-28 14:38 Felipe Alfaro Solana
@ 2003-02-28 19:14 ` Andrew Morton
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2003-02-28 19:14 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: linux-kernel
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> Maybe I did not express myself correctly in my previous message: there are no such
> delays. Since the moment I click Reply for the very first time until the window opens up,
> there is no disk idle time.
>
> > I'd suggest that you launch evolution from the command line in an xterm so
> > you can watch for any diagnostic messages.
>
> I have done so: Evolution is a complex application with many interdependencies and is
> not very prone to launch diagnostic messages to the console. Anyways, I haven't seen
> any diagnostic message in the console. I still think there is something in the AS I/O scheduler
> that is not working at full read throughput. Of course I'm no expert.
It certainly does appear that way. But you observed the same runtime
with the deadline scheduler. Or was that a typo?
> > 2.4.20-2.54 -> 9s
> > 2.5.63-mm1 w/Deadline -> 34s
> > 2.5.63-mm1 w/AS -> 33s
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
@ 2003-02-28 14:38 Felipe Alfaro Solana
2003-02-28 19:14 ` Andrew Morton
0 siblings, 1 reply; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-02-28 14:38 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
----- Original Message -----
From: Andrew Morton <akpm@digeo.com>
Date: Fri, 28 Feb 2003 04:44:07 -0800
To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> >
> > I have done benchmark tests with Evolution under the following conditions:
> > (times measured since the reply button is clicked until the message is
> > opened)
> >
> > 2.4.20-2.54 -> 9s
> > 2.5.63-mm1 w/Deadline -> 34s
> > 2.5.63-mm1 w/AS -> 33s
>
> Well something has gone quite wrong there. It sounds as if something in
> the 2.5 kernel has broken evolution.
>
> Does this happen every time you reply to a message or just the first time?
Only the first time.
> And if you reply to a message, then quit evolution, then restart evolution
> then reply to another message, does the same delay happen?
>
> The above tests will eliminate the IO system at least.
OK, it seems to me there's an IO delay here: The first time I reply to a message,
there is a continuous, steady and light disk load since I press the Reply button
until the message appears. There are no pauses or delays.
If I close the message window and then click Reply again, the window opens up
almost immediately. Also, if I exit Evolution completely (shut it down and run "killev"
to kill wombat and friends), and then open it up again, the Reply message procedure
is also immediate.
> If the delay is still there when all the needed datais in pagecache then
> please run `vmstat 1' during the operation and send the part of the trace
> from the period when the delay happens.
Maybe I did not express myself correctly in my previous message: there are no such
delays. Since the moment I click Reply for the very first time until the window opens up,
there is no disk idle time.
> I'd suggest that you launch evolution from the command line in an xterm so
> you can watch for any diagnostic messages.
I have done so: Evolution is a complex application with many interdependencies and is
not very prone to launch diagnostic messages to the console. Anyways, I haven't seen
any diagnostic message in the console. I still think there is something in the AS I/O scheduler
that is not working at full read throughput. Of course I'm no expert.
Thanks!
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-02-28 12:18 Felipe Alfaro Solana
@ 2003-02-28 12:44 ` Andrew Morton
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2003-02-28 12:44 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: linux-kernel
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> I have done benchmark tests with Evolution under the following conditions:
> (times measured since the reply button is clicked until the message is
> opened)
>
> 2.4.20-2.54 -> 9s
> 2.5.63-mm1 w/Deadline -> 34s
> 2.5.63-mm1 w/AS -> 33s
Well something has gone quite wrong there. It sounds as if something in
the 2.5 kernel has broken evolution.
Does this happen every time you reply to a message or just the first time?
And if you reply to a message, then quit evolution, then restart evolution
then reply to another message, does the same delay happen?
The above tests will eliminate the IO system at least.
If the delay is still there when all the needed datais in pagecache then
please run `vmstat 1' during the operation and send the part of the trace
from the period when the delay happens.
I'd suggest that you launch evolution from the command line in an xterm so
you can watch for any diagnostic messages.
Thanks.
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
@ 2003-02-28 12:18 Felipe Alfaro Solana
2003-02-28 12:44 ` Andrew Morton
0 siblings, 1 reply; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-02-28 12:18 UTC (permalink / raw)
To: akpm; +Cc: linux-kernel
----- Original Message -----
From: Andrew Morton <akpm@digeo.com>
Date: Thu, 27 Feb 2003 15:26:04 -0800
To: "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
> > Indeed, this can be tested interactively with an application like Evolution:
> > I have configured Evolution to use 2 dictionaries (English and Spanish) for
> > spell checking in e-mail messages. When running 2.4.20, if I choose to reply
> > to a large message, it only takes a few seconds to read both dictionaries
> > from disk and perform the spell checking.
> > However, on 2.5.63-mm1 the same process takes considerably longer. Any
> > reason for this?
>
> Could you boot with elevator-deadline and retest?
I have done benchmark tests with Evolution under the following conditions: (times measured since the reply
button is clicked until the message is opened)
2.4.20-2.54 -> 9s
2.5.63-mm1 w/Deadline -> 34s
2.5.63-mm1 w/AS -> 33s
The 2.4.20-2.54 is *not* a stock kernel, but Red Hat's own patched kernel (I think they include most of Alan Cox
patches). Times are measured manually (don't know how to "time" the time elapsed since I click a button and
the reply window is opened). Also, the filesystem is "ext2" running on a laptop (not a really fast hard disk).
> How large are the dictionary files?
Well, the aspell dictionary files are roughly 16MB for the Spanish dictionary and 4MB for the English one.
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
^ permalink raw reply [flat|nested] 17+ messages in thread
* Re: anticipatory scheduling questions
2003-02-27 22:24 Felipe Alfaro Solana
@ 2003-02-27 23:26 ` Andrew Morton
0 siblings, 0 replies; 17+ messages in thread
From: Andrew Morton @ 2003-02-27 23:26 UTC (permalink / raw)
To: Felipe Alfaro Solana; +Cc: linux-kernel
"Felipe Alfaro Solana" <felipe_alfaro@linuxmail.org> wrote:
>
> Hello,
>
> I have just installed 2.5.63-mm1 on my system and have been performing a very simple benchmarks. Here are
> my first results when compared against a RedHat 2.4.20-2.54 kernel:
>
> (All times expressed as total times)
>
> 1. time dd if=/dev/zero of=/tmp/p bs=1024k count=256
> 2.5.63-mm1 -> 0m12.737s
> 2.4.20-2.54 -> 0m17.704s
It's hard to compare 2.4 and 2.5 on this one. 2.5 will start writing to disk
much earlier, and that additional I/O can sometimes get in the way of other
disk operations. The end result is that the test exits leaving more (or
less) dirty data in memory and the time for writing that out is not
accounted.
You need to either run a much longer test, or include a `sync' in the
timings.
But in this case (assuming you're using ext3), the difference is probably
explained by a timing fluke - the test on 2.4 kernel happened to cover three
ext3 commit intervals while the 2.5 test squeezed itself into two.
Hard to say - there are a lot of variables here.
> 2. time cp /tmp/p /tmp/q
> 2.5.63-mm1 -> 0m41.108s
> 2.4.20-2.54 -> 0m51.939s
Could be ext3 effects as well. Also maybe some differences in page aging
implementations.
> 3. time cmp /tmp/p /tmp/q
> 2.5.63-mm1 -> 1m7.349s
> 2.4.20-2.54 -> 0m58.966s
cmp needs to use a larger buffer ;)
> 4. time cmp /dev/zero /tmp/q
> 2.5.63-mm1 -> 0m17.965s
> 2.4.20-2.54 -> 0m14.038s
Again, depends on how much of /tmp/q was left in pagecache.
> The question is, why, apparently, is anticipatory scheduling perfomring
> worse than 2.4.20?
It doesn't seem to be from the above numbers?
> Indeed, this can be tested interactively with an application like Evolution:
> I have configured Evolution to use 2 dictionaries (English and Spanish) for
> spell checking in e-mail messages. When running 2.4.20, if I choose to reply
> to a large message, it only takes a few seconds to read both dictionaries
> from disk and perform the spell checking.
> However, on 2.5.63-mm1 the same process takes considerably longer. Any
> reason for this?
Could you boot with elevator-deadline and retest?
How large are the dictionary files?
^ permalink raw reply [flat|nested] 17+ messages in thread
* anticipatory scheduling questions
@ 2003-02-27 22:24 Felipe Alfaro Solana
2003-02-27 23:26 ` Andrew Morton
0 siblings, 1 reply; 17+ messages in thread
From: Felipe Alfaro Solana @ 2003-02-27 22:24 UTC (permalink / raw)
To: linux-kernel
Hello,
I have just installed 2.5.63-mm1 on my system and have been performing a very simple benchmarks. Here are
my first results when compared against a RedHat 2.4.20-2.54 kernel:
(All times expressed as total times)
1. time dd if=/dev/zero of=/tmp/p bs=1024k count=256
2.5.63-mm1 -> 0m12.737s
2.4.20-2.54 -> 0m17.704s
2. time cp /tmp/p /tmp/q
2.5.63-mm1 -> 0m41.108s
2.4.20-2.54 -> 0m51.939s
3. time cmp /tmp/p /tmp/q
2.5.63-mm1 -> 1m7.349s
2.4.20-2.54 -> 0m58.966s
4. time cmp /dev/zero /tmp/q
2.5.63-mm1 -> 0m17.965s
2.4.20-2.54 -> 0m14.038s
The question is, why, apparently, is anticipatory scheduling perfomring worse than 2.4.20? Indeed, this can be
tested interactively with an application like Evolution: I have configured Evolution to use 2 dictionaries (English
and Spanish) for spell checking in e-mail messages. When running 2.4.20, if I choose to reply to a large
message, it only takes a few seconds to read both dictionaries from disk and perform the spell checking.
However, on 2.5.63-mm1 the same process takes considerably longer. Any reason for this?
Thanks!
Best regards,
Felipe Alfaro Solana
--
______________________________________________
http://www.linuxmail.org/
Now with e-mail forwarding for only US$5.95/yr
Powered by Outblaze
^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2003-03-02 21:40 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-02 11:40 anticipatory scheduling questions Felipe Alfaro Solana
2003-03-02 20:43 ` Andrew Morton
-- strict thread matches above, loose matches on Subject: below --
2003-03-02 21:50 Felipe Alfaro Solana
2003-03-01 14:48 Felipe Alfaro Solana
[not found] <fa.g5ol5kg.cgoq0g@ifi.uio.no>
[not found] ` <fa.hp882fv.1u0orj9@ifi.uio.no>
2003-03-01 12:48 ` Ed Tomlinson
2003-03-01 10:25 Felipe Alfaro Solana
2003-03-01 10:40 ` Andrew Morton
2003-03-01 11:51 ` David Lang
2003-03-01 17:15 ` Alan Cox
2003-02-28 23:12 Felipe Alfaro Solana
2003-02-28 23:16 ` Andrew Morton
2003-02-28 14:38 Felipe Alfaro Solana
2003-02-28 19:14 ` Andrew Morton
2003-02-28 12:18 Felipe Alfaro Solana
2003-02-28 12:44 ` Andrew Morton
2003-02-27 22:24 Felipe Alfaro Solana
2003-02-27 23:26 ` Andrew Morton
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).