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
"Felipe Alfaro Solana" <[email protected]> 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?
----- Original Message -----
From: Andrew Morton <[email protected]>
Date: Thu, 27 Feb 2003 15:26:04 -0800
To: "Felipe Alfaro Solana" <[email protected]>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <[email protected]> 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
"Felipe Alfaro Solana" <[email protected]> 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.
----- Original Message -----
From: Andrew Morton <[email protected]>
Date: Fri, 28 Feb 2003 04:44:07 -0800
To: "Felipe Alfaro Solana" <[email protected]>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <[email protected]> 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
"Felipe Alfaro Solana" <[email protected]> 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
----- Original Message -----
From: Andrew Morton <[email protected]>
Date: Fri, 28 Feb 2003 11:14:18 -0800
To: "Felipe Alfaro Solana" <[email protected]>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <[email protected]> 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
"Felipe Alfaro Solana" <[email protected]> wrote:
>
> ----- Original Message -----
> From: Andrew Morton <[email protected]>
> Date: Fri, 28 Feb 2003 11:14:18 -0800
> To: "Felipe Alfaro Solana" <[email protected]>
> Subject: Re: anticipatory scheduling questions
>
> > "Felipe Alfaro Solana" <[email protected]> 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.
----- 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
"Felipe Alfaro Solana" <[email protected]> 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.
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 <[email protected]>
> To: Felipe Alfaro Solana <[email protected]>
> Cc: [email protected]
> Subject: Re: anticipatory scheduling questions
>
> "Felipe Alfaro Solana" <[email protected]> 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Andrew Morton wrote:
> "Felipe Alfaro Solana" <[email protected]> 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
----- Original Message -----
From: Ed Tomlinson <[email protected]>
Date: Sat, 01 Mar 2003 07:48:45 -0500
To: Andrew Morton <[email protected]>, [email protected], [email protected]
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
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
----- Original Message -----
From: Andrew Morton <[email protected]>
Date: Sat, 1 Mar 2003 02:40:24 -0800
To: "Felipe Alfaro Solana" <[email protected]>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <[email protected]> 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
"Felipe Alfaro Solana" <[email protected]> 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.
----- Original Message -----
From: Andrew Morton <[email protected]>
Date: Sun, 2 Mar 2003 12:43:58 -0800
To: "Felipe Alfaro Solana" <[email protected]>
Subject: Re: anticipatory scheduling questions
> "Felipe Alfaro Solana" <[email protected]> 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