public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: Arjan van de Ven <arjanv@redhat.com>
Cc: Justin Cormack <kernel@street-vision.com>, linux-kernel@vger.kernel.org
Subject: Re: performance of O_DIRECT on md/lvm
Date: Sun, 20 Jan 2002 20:16:03 +0100	[thread overview]
Message-ID: <20020120201603.L21279@athlon.random> (raw)
In-Reply-To: <200201181743.g0IHhO226012@street-vision.com> <3C48607C.35D3DDFF@redhat.com>
In-Reply-To: <3C48607C.35D3DDFF@redhat.com>; from arjanv@redhat.com on Fri, Jan 18, 2002 at 05:50:53PM +0000

On Fri, Jan 18, 2002 at 05:50:53PM +0000, Arjan van de Ven wrote:
> Justin Cormack wrote:
> > 
> > Reading files with O_DIRECT works very nicely for me off a single drive
> > (for video streaming, so I dont want cacheing), but is extremely slow on
> > software raid0 devices, and striped lvm volumes. Basically a striped
> > raid device reads at much the same speed as a single device with O_DIRECT,
> > while reading the same file without O_DIRECT gives the expected performance
> > (but with unwanted cacheing).
> > 
> > raw devices behave similarly (though if you are using them you can probably
> > do your own raid0).
> > 
> > My guess is this is because of the md blocksizes being 1024, rather than
> > 4096: is this the case and is there a fix (my quick hack at md.c to try
> > to make this happen didnt work).
> 
> well not exactly. Raid0 is faster due to readahead (eg you read one
> block and the kernel 
> sets the OTHER disk also working in parallel in anticipation of you
> using that). O_DIRECT
> is of course directly in conflict with this as you tell the kernel that
> you DON'T want
> any optimisations....

if you read in chunks of a few mbytes per read syscall, the lack of
readahead shouldn't make much difference (this is true for both raid and
standalone device). If there's a relevant difference it's more liekly an
issue with the blocksize.

Andrea

  reply	other threads:[~2002-01-20 19:15 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-18 17:43 performance of O_DIRECT on md/lvm Justin Cormack
2002-01-18 17:50 ` Arjan van de Ven
2002-01-20 19:16   ` Andrea Arcangeli [this message]
     [not found] <200201181743.g0IHhO226012@street-vision.com.suse.lists.linux.kernel>
     [not found] ` <3C48607C.35D3DDFF@redhat.com.suse.lists.linux.kernel>
     [not found]   ` <20020120201603.L21279@athlon.random.suse.lists.linux.kernel>
2002-01-20 21:28     ` Andi Kleen
2002-01-20 21:42       ` arjan
2002-01-21  1:12       ` Andrea Arcangeli
2002-01-21  5:35         ` Benjamin LaHaise
2002-01-21 14:41           ` Andrea Arcangeli
     [not found] <p734rlg90ga.fsf@oldwotan.suse.de.suse.lists.linux.kernel>
     [not found] ` <m16SPj2-000OVeC@amadeus.home.nl.suse.lists.linux.kernel>
2002-01-20 22:11   ` Andi Kleen

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=20020120201603.L21279@athlon.random \
    --to=andrea@suse.de \
    --cc=arjanv@redhat.com \
    --cc=kernel@street-vision.com \
    --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