Re: anticipatory scheduling questions

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

[-- 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 --]

Re: anticipatory scheduling questions

[Andrew Morton]

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

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

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

Re: anticipatory scheduling questions

[Alan Cox]

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

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

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

Re: anticipatory scheduling questions

[Ed Tomlinson]

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

Re: anticipatory scheduling questions

[David Lang]

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

Re: anticipatory scheduling questions

[Andrew Morton]

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

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

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

Re: anticipatory scheduling questions

[Andrew Morton]

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

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

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

Re: anticipatory scheduling questions

[Andrew Morton]

"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 

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

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

Re: anticipatory scheduling questions

[Andrew Morton]

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

Re: anticipatory scheduling questions

[Felipe Alfaro Solana]

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

Re: anticipatory scheduling questions

[Andrew Morton]

"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?

anticipatory scheduling questions

[Felipe Alfaro Solana]

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