public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Patrick Lauer <patrick@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: [gentoo-dev] Optimizing performance
Date: Thu, 15 Dec 2005 13:48:05 +0100	[thread overview]
Message-ID: <1134650885.4634.57.camel@localhost> (raw)

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

Hi all,

I was wondering if there are any sane ways to optimize the performance
of a Gentoo system.
Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to
make things unstable, which is of course not what we want. The "easy"
way out would be buying faster hardware, but that is usually not an
option ;-)

So ... what can be done to get the stable maximum out of your hardware?

In my experience (x86 centric - do other arches have different
"problems"?) the following is stable, but not necessarily the optimum:
- don't overtweak CFLAGS. "-O2 -march=$your_cpu_family" seems to be on
average the best, -O3 is often slower and can cause bugs
- don't do anything with ASFLAGS, LDFLAGS. This causes weird random
breakage (e.g. LDFLAGS="-O1" causes prelink to fail with "absurd"
errors) and doesn't give a noticeable performance boost
- check that all IDE disks use DMA mode, otherwise they are limited to
~16M/s with a huge CPU usage penalty. Sometimes (application-specific)
increasing the readahead with hdparm gives a huge throughput boost.
- kernel tweaks like preempt may increase the responsiveness of the
system, but often reduce throughput and may have unexpected sideeffects
like random audio stutter as well as random kernel crashes ;-)
- kernel tweaks like setting swappiness or using a different I/O
scheduler (CFQ, deadline) should help, but I'm not aware of any "real"
benchmarks except microbenchmarks (can create 1M files 10% faster!!!!! -
yes, but how does it behave with a normal workload?)
- using a "smarter" filesystem can dramatically improve performance at
the potential cost of reliability. As data on FS reliability is hard to
find from unbiased sources this becomes a religious issue ... migrating
from ext3 to reiserfs makes "emerge sync" extremely much faster, but is
reiserfs sustainable?

Are there any application-specific tweaks (e.g. "use the prefork MPM
with apache2")? What is known to break things, what has usually
beneficial behaviour? Are there any useful benchmarks that show the
performance difference between different settings?

Thanks for your input,

Patrick
-- 
Stand still, and let the rest of the universe move

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

             reply	other threads:[~2005-12-15 12:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-12-15 12:48 Patrick Lauer [this message]
2005-12-15 13:43 ` [gentoo-dev] Optimizing performance Francesco Riosa
2005-12-15 14:17   ` Diego 'Flameeyes' Pettenò
2005-12-15 16:00   ` Patrick Lauer
2005-12-15 16:57     ` Matthijs van der Vleuten
2005-12-15 14:13 ` Chris Gianelloni
2005-12-15 18:08   ` Wernfried Haas
2005-12-15 18:39     ` Curtis Napier
2005-12-15 14:43 ` [gentoo-dev] " Duncan
2005-12-15 15:43   ` Patrick Lauer
2005-12-15 15:50     ` Donnie Berkholz
2005-12-23 17:28       ` Paul de Vrieze
2005-12-23 17:36         ` Donnie Berkholz
2005-12-23 17:58           ` Lares Moreau
2005-12-15 16:03     ` Diego 'Flameeyes' Pettenò
2005-12-15 17:49       ` [gentoo-dev] " Duncan
2005-12-15 17:06     ` [gentoo-dev] " Francesco Riosa
2005-12-15 15:58 ` [gentoo-dev] " Nathaniel McCallum
2005-12-15 18:38 ` John Myers
2005-12-23 17:35   ` Paul de Vrieze
2005-12-23 23:52     ` Diego 'Flameeyes' Pettenò
2005-12-24  2:08       ` John Myers
2005-12-24 11:37       ` Kevin F. Quinn
2005-12-24 12:05         ` Diego 'Flameeyes' Pettenò
2005-12-27 15:38       ` Paul de Vrieze
2005-12-28  5:37         ` [gentoo-dev] " Duncan
2005-12-28  9:50           ` Duncan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1134650885.4634.57.camel@localhost \
    --to=patrick@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox