public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Marinos J. Yannikos" <mjy@geizhals.at>
To: linux-kernel@vger.kernel.org
Subject: CONFIG_PREEMPT and server workloads
Date: Thu, 18 Mar 2004 05:00:01 +0100	[thread overview]
Message-ID: <40591EC1.1060204@geizhals.at> (raw)

Hi,

we upgraded a few production boxes from 2.4.x to 2.6.4 recently and the 
default .config setting was CONFIG_PREEMPT=y. To get straight to the 
point: according to our measurements, this results in severe performance 
degradation with our typical and some artificial workload. By "severe" I 
mean this:

---

1. "production" load(*), kernel-compiles (make -j5, in both cases 
kernels with CONFIG_PREEMPT=n were compiled), dual Xeon 3,06GHz/4GB RAM, 
SMP+HT.

2.6.4 with CONFIG_PREEMPT=y:
real    4m41.741s
user    6m13.631s
sys     0m43.729s

2.6.4 with CONFIG_PREEMPT=n:
real    2m20.424s
user    5m54.498s
sys     0m37.297s

The slowness during the compilation was very noticeable on the console.

2. artificial load(**), kernel-compiles (make -j5), single 2,8GHz P4 
with SMP+HT:

2.6.4 with CONFIG_PREEMPT=y:
real    7m40.933s
user    5m42.454s
sys     0m28.114s

2.6.4 with CONFIG_PREEMPT=n:
real    7m13.735s
user    4m56.266s
sys     0m35.495s

3. no noticeable slowdown with no load at all during the benchmarking 
was observed.

(*) busy webserver doing apache/mod_perl stuff, ~40 static/~10 dynamic 
hits/sec, ~20% CPU usage; typical load has no significant 
jumps/anomalies in this time frame (it's also one of 3 boxes in a 
cluster with a hardware load balancer)
(**) "ab -n 100000 -c2 <some simple CGI script>" from another box 
running at the same time
---

Now, we can go into details about our methodology and what else may have 
been borked about our boxes, but what I'm wondering about is (assuming 
that we didn't mess things up somewhere and other people can confirm 
this!): why in the world would anyone want CONFIG_PREEMPT=y as a default 
setting when it has such an impact on performance in actual production 
environments? Is 2.6 intended to become the "Desktop Linux" code path? 
If not, shouldn't there be a big warning sticker somewhere that says 
"DON'T EVEN THINK ABOUT KEEPING THIS DEFAULT SETTING UNLESS ALL YOU WANT 
TO DO IS LISTEN TO MP3 AUDIO WHILE USING XFREE86!"? I've been skimming 
over older lkml postings about performance problems with 2.6.x and many 
of them, while obviously being about systems with CONFIG_PREEMPT=y, 
don't even mention the fact that the degradation might be because of 
that setting. Noone seems to know/care. Why?

Regards,
  Marinos
-- 
Dipl.-Ing. Marinos Yannikos, CEO
Preisvergleich Internet Services AG
Franzensbrückenstraße 8/2/16, A-1020 Wien
Tel./Fax: (+431) 5811609-52/-55

             reply	other threads:[~2004-03-18  3:55 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18  4:00 Marinos J. Yannikos [this message]
2004-03-18  5:12 ` CONFIG_PREEMPT and server workloads Andrew Morton
2004-03-18  6:03 ` Andrea Arcangeli
2004-03-18  9:50   ` Andrew Morton
2004-03-18 14:51     ` Andrea Arcangeli
2004-03-18 15:34       ` Robert Love
2004-03-18 16:01         ` Andrea Arcangeli
2004-03-18 17:39       ` Andrew Morton
2004-03-18 17:58         ` Andrea Arcangeli
2004-03-18 18:26           ` Andrew Morton
2004-03-18 18:38             ` Andrea Arcangeli
2004-03-18 18:47               ` Andrew Morton
2004-03-18 19:01                 ` Andrea Arcangeli
2004-03-18 17:48       ` Robert Love
2004-03-18 18:00         ` Andrea Arcangeli
2004-03-20 10:48         ` Jamie Lokier
2004-03-19  2:17       ` Nick Piggin
     [not found]         ` <20040319050948.GN2045@holomorphy.com>
2004-03-20 12:14           ` Andrea Arcangeli
2004-03-20 14:51             ` William Lee Irwin III
2004-03-20 15:03               ` Andrea Arcangeli
2004-03-20 15:09                 ` William Lee Irwin III
2004-03-24 13:57                 ` Takashi Iwai
2004-03-24 14:52                   ` Andrea Arcangeli
2004-03-24 15:11                   ` William Lee Irwin III
2004-03-18 15:20     ` Tom Sightler
2004-03-18 15:37       ` Andrea Arcangeli
2004-03-18 23:54         ` Tom Sightler
2004-03-18 15:39       ` Robert Love
2004-03-18 15:28   ` Takashi Iwai
2004-03-18 15:40     ` Robert Love
2004-03-18 15:42     ` Andrea Arcangeli
2004-03-18 19:01     ` Andrew Morton
2004-03-18 19:08       ` Takashi Iwai
2004-03-18 19:18         ` Andrew Morton
2004-03-18 19:20           ` Takashi Iwai
2004-03-18 19:43             ` Andrea Arcangeli
2004-03-18 19:50               ` Takashi Iwai
2004-03-18 19:24         ` Robert Love
2004-03-19 22:03           ` Valdis.Kletnieks
2004-03-19 22:12             ` Robert Love
2004-03-24 15:00               ` Takashi Iwai
2004-03-18 19:16       ` Takashi Iwai
2004-03-18 19:29         ` Andrew Morton
2004-03-18 19:48           ` Chris Mason
2004-03-19 11:37             ` Takashi Iwai
2004-03-19 13:46               ` Chris Mason
2004-03-19 14:06                 ` Takashi Iwai
     [not found]         ` <20040318221006.74246648.akpm@osdl.org>
2004-03-19 10:30           ` Takashi Iwai
2004-03-23  9:14             ` Dipankar Sarma
2004-03-19 17:22           ` Dipankar Sarma
2004-03-19 18:03             ` Andrew Morton
2004-03-20 12:24             ` Andrea Arcangeli
2004-03-20 13:13               ` Dipankar Sarma
2004-03-18 19:39       ` Andrea Arcangeli
2004-03-18 22:32     ` Andrew Morton
2004-03-18 22:54       ` Chris Mason
2004-03-18 23:57         ` Andrew Morton
2004-03-19 20:46           ` Takashi Iwai
2004-03-19 21:08             ` Andrew Morton
2004-03-19  3:07     ` Eric St-Laurent
2004-03-19 11:23       ` Takashi Iwai
2004-03-19 13:35         ` Chris Mason

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=40591EC1.1060204@geizhals.at \
    --to=mjy@geizhals.at \
    --cc=linux-kernel@vger.kernel.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