public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <htejun@gmail.com>
To: "Martin A. Fink" <fink@mpe.mpg.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SATA-performance: Linux vs. FreeBSD
Date: Thu, 15 Feb 2007 14:48:53 +0900	[thread overview]
Message-ID: <45D3F445.1030708@gmail.com> (raw)
In-Reply-To: <200702121502.17130.fink@mpe.mpg.de>

Hello, Martin.

Martin A. Fink wrote:
> Test					OpenSuSE(AHCI)			FreeBSD(AHCI)
> ---------------------------------------------------------------------------------------------------------------------------------------
> SSD(vfat 25GB)			41+/-2 MB/s at 4-10%		15+/-0 MB/s at 2% CPU
> SSD(raw  25GB) 		26+/-1 MB/s at 4-10% CPU	48+/-0 MB/s at 1% CPU
> SSD(ext3 25GB)		39+/-5 MB/s at 10-15% CPU	34+/-0 MB/s at 14% CPU
> SSD(ext2 25GB)		42+/-1 MB/s at 10-15% CPU	32+/-0 MB/s at 10% CPU
> ---------------------------------------------------------------------------------------------------------------------------------------
> 
> Test					OpenSuSE (AHCI off)		FreeBSD (AHCI off)
> ---------------------------------------------------------------------------------------------------------------------------------------
> SSD(vfat 25GB)			22+/-4 MB/s at 6-19% CPU	--
> SSD(raw  25GB)		33+/-4 MB/s at 7-14% CPU	41+/-0 MB/s at 1% CPU
> SSD(ext2 25GB)		27+/-6 MB/s at 6-14% CPU	--
> ---------------------------------------------------------------------------------------------------------------------------------------
> 
> Question 1:
> Can anybody explain to me, why writing to a SATA-I device with AHCI consumes 
> so much CPU time using Linux, while it takes almost no CPU time on FreeBSD 
> 6.2 ? Especially comparing values of writing to the raw device?

Can't tell.  AHCI needs very few MMIOs to perform each request.  As Andi 
suggested, please do oprofile.  It's easy.

> Question 2:
> Can anybody explain to me, why writing to a solid state disk (a kind of memory 
> that always has the same constant bandwidth) has such big standard errors in 
> writing rate using Linux (between 1 to 6 MB/s error) while FreeBSD gives an 
> almost constant writing rate (as one would expect it for a SSD) ?

The default iosched is heavily optimized for regular disks with moving 
head and for more usual workload.  Requests are sometimes paused to wait 
for requests in adjacent area.  Use deadline or noop for ssd.

Also, try turn off NCQ.  Some of early drives from major disk vendors 
had all kinds of issues with NCQ implementation.  SSD firmwares don't 
tend to be of high quality.

> Question 3:
> Why is writing to a raw device in Linux slower than using e.g. ext2 ? And why 
> is Linux writing rate much lower (-12.5 % for the best case) compared to 
> writing rate of FreeBSD?

As written above, the first thing I can think of is interaction with 
iosched.  SSD and your workload are pretty unusual.

> Question 4:
> When writing to the SATA-II HDD Linux is around 10% slower than FreeBSD when 
> using ext3, but around as fast as FreeBSD when writing raw. Why?

Dunno much about that.  Where's the test result?

> How can I improve the speed of Linux,

Other ppl have pointed out but use /dev/sdX not the raw devices.  If you 
use raw, you end up writing each chunk synchronously.

-- 
tejun


      parent reply	other threads:[~2007-02-15 16:03 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-12 14:02 SATA-performance: Linux vs. FreeBSD Martin A. Fink
2007-02-12 17:04 ` Andi Kleen
2007-02-12 16:27   ` Martin A. Fink
2007-02-12 18:41     ` Andi Kleen
2007-02-12 17:56       ` Martin A. Fink
2007-02-12 18:17         ` Ray Lee
2007-02-12 19:08         ` Alan
2007-02-12 20:34           ` Nigel Cunningham
2007-02-13  9:34           ` Martin A. Fink
2007-02-13 11:25             ` Alan
2007-02-13 12:32               ` Martin A. Fink
2007-02-13 14:47                 ` Theodore Tso
2007-02-13 15:03                   ` Alan
2007-02-13 17:12               ` Jeff Garzik
2007-02-12 23:31         ` Matthias Schniedermeyer
2007-02-13  9:25           ` Martin A. Fink
2007-02-13 10:08             ` Arjan van de Ven
2007-02-13 11:18               ` Andi Kleen
2007-02-13 10:25                 ` Arjan van de Ven
2007-02-13 11:27               ` Alan
2007-02-13 11:59                 ` Jörn Engel
2007-02-13 19:54               ` Jeffrey Hundstad
2007-02-13 10:16             ` Matthias Schniedermeyer
2007-02-13 10:29               ` Martin A. Fink
2007-02-13 12:04                 ` Jörn Engel
2007-02-13 12:24                 ` Matthias Schniedermeyer
2007-02-13 12:49                   ` Martin A. Fink
2007-02-13 13:53                     ` Matthias Schniedermeyer
2007-02-12 16:37   ` Martin A. Fink
2007-02-12 18:19     ` Stefan Richter
2007-02-13 19:09     ` Jeff Carr
2007-02-12 17:42   ` Martin A. Fink
2007-02-15  5:48 ` Tejun Heo [this message]

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=45D3F445.1030708@gmail.com \
    --to=htejun@gmail.com \
    --cc=fink@mpe.mpg.de \
    --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