All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: "Martin A. Fink" <fink@mpe.mpg.de>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SATA-performance: Linux vs. FreeBSD
Date: 12 Feb 2007 19:41:27 +0100	[thread overview]
Message-ID: <p731wkvi5go.fsf@bingen.suse.de> (raw)
In-Reply-To: <200702121727.17108.fink@mpe.mpg.de>

"Martin A. Fink" <fink@mpe.mpg.de> writes:

Your mailer seems to be broken. It drops cc.
> 
> If you call fsync in BSD then you get what you expect. anything that is still 
> not on disk will be written. Afterwards fsync returns... So this should be 
> the same like with linux?!

Not necessarily.  The disk may buffer additionally. Handling that
differs widely, but modern Linux forces flushes to platter if the hardware support 
it.

> But the big question still is -- buffered or not -- where do the big 
> variations within linux come frome? I am not writing small blocks. I write 
> huge amounts of data.

1MB is nowhere near huge by modern standards. Many IO subsystems are
only happy with multi MB requests. 

> So the buffer will always be full.

Hardly. Especially not if you do synchronous fsync inbetween.

> If I use a normal SATA-II disk, there are no differences between BSD and Linux 
> when writing to the raw device... So it cant be a buffer-problem alone.

Yes that is something that needs to be investigated. That is why I suggested
oprofile if your assertation of a more CPU overhead on Linux is true.

> I still don't understand the buffer argument. If one writes 25 GB in blocks of 
> 1 MB your buffer should be always full...

Your mental model of a IO subsystem seems to be quite off.
Think what happens when you fsync and submit synchronously.

It's like sending something down a long pipe and waiting until it arrives
at the bottom and you hear the echo of the impact. Then only then you send again. 
There will be always long periods when the pipe will be empty.

If you use large enough blocks these gaps will be quite small and
might effectively become unimportant, but 1MB is nowhere near big enough 
for that.

> Is there a buffered io device that I can use, but that does not use a 
> filesystem?

/dev/sdX*. However it has some other issues that also don't make
it ideal. File systems are usually best.

-Andi

  reply	other threads:[~2007-02-12 17:41 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 [this message]
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

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=p731wkvi5go.fsf@bingen.suse.de \
    --to=andi@firstfloor.org \
    --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 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.