Performance Tuning

Performance Tuning

[john weber]

I've been comparing kernel compile stats online to those I get 
on my own machine, and I am baffled.

Kernel compiles take 6m38s on my P4 2.8GHz (with HT enabled) and 
512 MB RAM as compared to 20-30 seconds reported by folks online. 
I am running kernel 2.6.6.

While I understand that this varies with the config, I also don't 
see why it should vary so much.  Does anyone have any pointers on 
how I could best troubleshoot my performance?

Re: Performance Tuning

[Richard B. Johnson]

Re: Performance Tuning

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 807 bytes --]

On Thu, 20 May 2004 12:05:15 -0000, john weber <weber@sixbit.org>  said:

> Kernel compiles take 6m38s on my P4 2.8GHz (with HT enabled) and 
> 512 MB RAM as compared to 20-30 seconds reported by folks online. 
> I am running kernel 2.6.6.
> 
> While I understand that this varies with the config, I also don't 
> see why it should vary so much.  Does anyone have any pointers on 
> how I could best troubleshoot my performance?

Step 1: Buy a machine that has 16 CPUs and 32G of memory.

Step 2: cd /usr/src/linux-2.6.6 && make -j20

Step 3: Stand back :)

Seriously - the only way to do a kernel build in 20 seconds is to use 'make
-j20' or so, and have enough processors to handle it, and enough RAM so that
you can basically do the whole thing in the fin-core cache rather than beating
on the disk....


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: Performance Tuning

[Prakash K. Cheemplavam]

Valdis.Kletnieks@vt.edu wrote:
> On Thu, 20 May 2004 12:05:15 -0000, john weber <weber@sixbit.org>  said:
> 
> 
>>Kernel compiles take 6m38s on my P4 2.8GHz (with HT enabled) and 
>>512 MB RAM as compared to 20-30 seconds reported by folks online. 
>>I am running kernel 2.6.6.
[snip]
> Seriously - the only way to do a kernel build in 20 seconds is to use 'make
> -j20' or so, and have enough processors to handle it, and enough RAM so that
> you can basically do the whole thing in the fin-core cache rather than beating
> on the disk....

20sec sounds very far from reality for me. I have athlon xp@2.2GHz and 
with gcc3.4 it takes about 4min to compile a 2.6.6-mm kernel. Using 
gcc3.3.x it needs minutes more.

Prakash

Re: Performance Tuning

[cliff white]

On Thu, 20 May 2004 12:05:15 +0000
john weber <weber@sixbit.org> wrote:

> I've been comparing kernel compile stats online to those I get 
> on my own machine, and I am baffled.
> 
> Kernel compiles take 6m38s on my P4 2.8GHz (with HT enabled) and 
> 512 MB RAM as compared to 20-30 seconds reported by folks online. 
> I am running kernel 2.6.6.
> 
> While I understand that this varies with the config, I also don't 
> see why it should vary so much.  Does anyone have any pointers on 
> how I could best troubleshoot my performance?

That sounds about right for your hardware. As Valdis mentioned, 20 second
compiles just don't happen on UP machines, at least not at that clock speed.
cliffw

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


-- 
The church is near, but the road is icy.
The bar is far, but i will walk carefully. - Russian proverb

Re: Performance Tuning

[Tim Bird]

john weber wrote:
> I've been comparing kernel compile stats online to those I get 
> on my own machine, and I am baffled.
> 
> Kernel compiles take 6m38s on my P4 2.8GHz (with HT enabled) and 
> 512 MB RAM as compared to 20-30 seconds reported by folks online. 
> I am running kernel 2.6.6.
> 
> While I understand that this varies with the config, I also don't 
> see why it should vary so much.  Does anyone have any pointers on 
> how I could best troubleshoot my performance?

I have used compiler cache, and gotten about 30-second
compiles, after the first one, on a P4 3.0GHz.

See:  http://ccache.samba.org/

However, this isn't addressing performance of your machine, per-se.

=============================
Tim Bird
Architecture Group Co-Chair
CE Linux Forum
Senior Staff Engineer
Sony Electronics
E-mail: Tim.Bird@am.sony.com
=============================

Re: Performance Tuning

[Bill Davidsen]

john weber wrote:
> I've been comparing kernel compile stats online to those I get 
> on my own machine, and I am baffled.
> 
> Kernel compiles take 6m38s on my P4 2.8GHz (with HT enabled) and 
> 512 MB RAM as compared to 20-30 seconds reported by folks online. 
> I am running kernel 2.6.6.
> 
> While I understand that this varies with the config, I also don't 
> see why it should vary so much.  Does anyone have any pointers on 
> how I could best troubleshoot my performance?

If you are not using "make -j3" for your build you should be able to 
pick up 20-30% improvement, assuming that you have an SMP kernel running.

-- 
    -bill davidsen (davidsen@tmr.com)
"The secret to procrastination is to put things off until the
  last possible moment - but no longer"  -me

How can execute .cpp program with gcc command

[kranthi]

How can  execute .cpp program with  gcc command

Plz..

-- 
Using Opera's revolutionary e-mail client: http://www.opera.com/m2/

Performance tuning

[Vikas]

Hi ,
Can anyone tell me about library optimizer (monta vista )
Or do any one provide some pointer on library optimization ...

Performance tuning

[David Dougall]

Looking through the nfs-howto chapter 5 "Optimizing NFS Performance", I
found a few ambiguous statements and was wondering if I could get some
clarification.
There is a suggestion to increase rmem_default and rmem_max in
/proc/sys/net/core to "at least 256k".  What is the limit on that?  If I
have a server withs gobs of memory, how high can I increase that to still
get performance improvements.  Are there some statistics I can use to
measure if increases in this are helping.  Also, should I also increase
wmem_default and wmem_max.  It makes no mention of that in the howto.

With respect to Overflow of fragmented packets, it mentions the 2.2
kernel, but never mentions the 2.4.  Is it the same?  If so, it might be
nice to clear that up in the howto.  It also states that there is no ideal
value for this.  Any suggestions for specific traffic patterns?

Thanks
--David Dougall






-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Performance tuning

[Tom McNeal]

Hi -

I gleaned that tuning info from the SPECsfs and SPECweb99 
benchmarks, and documented it on the Mission Critical Linux
servers that are still kept on line:
http://www.missioncriticallinux.com/orph/ServerNotes.pdf

The latest howtos, which have been getting updated over the 
last few months, and are just about ready to go, contain an
updated discussion about [rw]mem_*, where I use the same examples,
but note that they apply to both read and write parameters.

As for limits, my paper notes much higher values than I was 
really willing to state in the howto.  Note that benchmarks are
often not real-world environments (I should probably remove the
"often" qualifier), so be sure to treat these suggestions with
a bit of skepticism.

I also corrected the fragmentation part to refer to all kernels.
The main thing to look for is MTU, plus the number of reassambly
failures noted as "reasmfails" in /proc/net/snmp, especially when
you start using 32K in udp (which is probably not the best idea).

Regards -

Tom


David Dougall wrote:
> 
> Looking through the nfs-howto chapter 5 "Optimizing NFS Performance", I
> found a few ambiguous statements and was wondering if I could get some
> clarification.
> There is a suggestion to increase rmem_default and rmem_max in
> /proc/sys/net/core to "at least 256k".  What is the limit on that?  If I
> have a server withs gobs of memory, how high can I increase that to still
> get performance improvements.  Are there some statistics I can use to
> measure if increases in this are helping.  Also, should I also increase
> wmem_default and wmem_max.  It makes no mention of that in the howto.
> 
> With respect to Overflow of fragmented packets, it mentions the 2.2
> kernel, but never mentions the 2.4.  Is it the same?  If so, it might be
> nice to clear that up in the howto.  It also states that there is no ideal
> value for this.  Any suggestions for specific traffic patterns?
> 
> Thanks
> --David Dougall
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Two, two, TWO treats in one.
> http://thinkgeek.com/sf
> _______________________________________________
> NFS maillist  -  NFS@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs

--
------------------------------------------------------------
Tom McNeal       trmcneal@attbi.com     (650)906-0761 (cell) 
------------------------------------------------------------


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

Re: Performance tuning

[Trond Myklebust]

>>>>> " " == Tom McNeal <trmcneal@attbi.com> writes:

     > I also corrected the fragmentation part to refer to all
     > kernels.  The main thing to look for is MTU, plus the number of
     > reassambly failures noted as "reasmfails" in /proc/net/snmp,
     > especially when you start using 32K in udp (which is probably
     > not the best idea).

Note that the number of reassembly failures is particularly inflated
if you are using a Linux client due to a bug in the socket layer: if
there is not enough buffer to send off all the fragments, then the
socket will still send off those fragments for which there is enough
space.
On the server side, this means that it will accumulate junk fragments
which never have a chance of being reassembled.

This 'feature' alone suffices to slow down the write speed to ~50% on
my test setup.

Cheers,
  Trond


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Two, two, TWO treats in one.
http://thinkgeek.com/sf
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs