All of lore.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: Thomas Molina <tmolina@cablespeed.com>
Cc: Linus Torvalds <torvalds@osdl.org>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.6.0 performance problems
Date: Tue, 30 Dec 2003 13:35:38 -0800	[thread overview]
Message-ID: <20031230213538.GH22503@holomorphy.com> (raw)
In-Reply-To: <Pine.LNX.4.58.0312301524220.3152@localhost.localdomain>

On Tue, Dec 30, 2003 at 04:14:13PM -0500, Thomas Molina wrote:
> I also get 90+ percent iowait under 2.6 and 0 iowait in 2.4.  I'm not sure 
> how the alleged suckiness of 2.6 paging fits into this.  On this system 
> the execution times are almost the same.  On this machine, in addition to 
> the iowait differences, there are cpu use statistics as reported by top.  
> On 2.4 idle time is 70 percent while on 2.6 the idle time is near zero 
> percent.  I'm not sure what the significance of this is.

2.4 does not report iowait; all iowait is reported as idle time on 2.4.

On Tue, Dec 30, 2003 at 04:14:13PM -0500, Thomas Molina wrote:
> CPU: PIII, speed 648.072 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (clocks processor is not halted) with a unit mask of 0x00 (No unit mask) count 324036
> vma      samples  %           symbol name
> c0115e20 22498    22.6776     mark_offset_tsc
> c0110080 12707    12.8084     mask_and_ack_8259A
> c018eec0 7115      7.1718     ext3_find_entry
> c010ff60 4013      4.0450     enable_8259A_irq
> c0168d50 2650      2.6712     __d_lookup
> c015eb10 1727      1.7408     link_path_walk
> c010afd0 1482      1.4938     irq_entries_start

Well, it looks like Linus said various things along these lines in
various ways before I finished writing this, but in case hearing it a
second time is any reassurance:

There's a slight problem here in that you're io-bound, not cpu-bound,
so profiles won't actually tell us much about remaining overheads.

One thing here is that since turning off all the debugging options got
you down to about a 15% degradation, things aren't actually
looking anywhere near as problematic as before when you had a near 90%
degradation. One possible explanation is that the extensive padding
done by CONFIG_DEBUG_PAGEALLOC created significant memory pressure.

If you'd like further speedups, logging the things I suggested earlier
and trying fiddling with swappiness might help.

In fact, you are down to such a small margin of degradation that the
remaining degradation vs. 2.4 may in fact be due to using oprofile,
which has significant, though not overwhelming overhead.


-- wli

  parent reply	other threads:[~2003-12-30 21:35 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-29 22:07 2.6.0 performance problems Thomas Molina
2003-12-29 22:21 ` Linus Torvalds
2003-12-29 22:58   ` Thomas Molina
2003-12-29 23:04     ` Linus Torvalds
2003-12-30 14:14       ` Thomas Molina
2003-12-30 14:39         ` William Lee Irwin III
2003-12-30 21:14           ` Thomas Molina
2003-12-30 21:23             ` Linus Torvalds
2003-12-31  0:50               ` Thomas Molina
2003-12-31  1:01                 ` Linus Torvalds
2003-12-31  1:34                 ` Andrew Morton
2003-12-31 11:25                   ` bert hubert
2003-12-30 21:35             ` William Lee Irwin III [this message]
2003-12-30 23:46             ` Roger Luethi
2003-12-30 18:20         ` Linus Torvalds
2003-12-29 23:14     ` Martin Schlemmer
2003-12-30  5:09       ` William Lee Irwin III
2003-12-30 10:27         ` Thomas Molina
2003-12-29 23:25     ` David B. Stevens
2003-12-29 23:05   ` Thomas Molina
2003-12-29 23:43     ` Martin Schlemmer
2003-12-30  0:17       ` Thomas Molina
2003-12-30  1:23         ` Martin Schlemmer
2003-12-30  1:27         ` Dave Jones
2003-12-30  1:37           ` Martin Schlemmer
2003-12-30  1:40             ` Dave Jones
2003-12-30  1:49             ` Thomas Molina
2003-12-30  2:03               ` Mike Fedyk
2004-01-03 19:37     ` Bill Davidsen
2003-12-30  1:25 ` Roger Luethi
2003-12-30  1:37   ` Thomas Molina
2003-12-30 19:21     ` Andy Isaacson
2003-12-30 19:40       ` William Lee Irwin III
2003-12-30 22:24         ` Roger Luethi
2003-12-31  0:33           ` Thomas Molina
2003-12-31 10:17             ` Roger Luethi
2003-12-31 11:21               ` Jens Axboe
2003-12-31 21:03                 ` Roger Luethi
2004-01-01  1:27                   ` Thomas Molina
2004-01-01 10:23                     ` Roger Luethi
2004-01-01 23:09                 ` Roger Luethi
2004-01-02 10:11                   ` Jens Axboe
2003-12-30  1:27 ` Thomas Molina
2003-12-30  2:53   ` Thomas Molina
  -- strict thread matches above, loose matches on Subject: below --
2003-12-30 11:41 Samium Gromoff
2004-01-03 19:54 ` Bill Davidsen
     [not found] ` <200312300855.00741.edt@aei.ca>
2004-01-05 12:33   ` Samium Gromoff
2004-01-05 15:09     ` Ed Tomlinson
2004-01-06  2:23       ` David Lang
2004-01-06 14:44         ` Samium Gromoff

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=20031230213538.GH22503@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tmolina@cablespeed.com \
    --cc=torvalds@osdl.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.