All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrea Arcangeli <andrea@suse.de>
To: simon@baydel.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: raw devices
Date: Thu, 20 Dec 2001 18:05:47 +0100	[thread overview]
Message-ID: <20011220180547.C1395@athlon.random> (raw)
In-Reply-To: <3C21D809.6787.13E19F@localhost>
In-Reply-To: <3C21D809.6787.13E19F@localhost>; from simon@baydel.com on Thu, Dec 20, 2001 at 12:22:33PM -0000

On Thu, Dec 20, 2001 at 12:22:33PM -0000, simon@baydel.com wrote:
> I have been performing some tests on raw devices, the results of 
> which I do not understand. I have 4 FC busses, each with one  
> SCSI disk, connect to a Linux system running 2.4.16. I use the raw 
> command to bind /dev/raw1 - /dev/raw4 to each of the devices. 
> With one process per raw device, running large sequential reads, I 
> got a total throughput  of 340 Megabytes per second. I also 
> observed 85% CPU idle. Following this I performed some more 
> tests and then returned to this one. This time the total had gone 
> down to 180 and there was no free CPU. I realized that the first 
> time I ran the tests, each of the disks that the raw devices were 
> mapped to were mounted. I then verified that this data was being 
> transferred along the FC bus using an analyzer while the devices 
> were mounted. Can anyone explain this to me ? I find it hard to 
> believe that the disk should be permitted to be mounted when 
> using raw device mappings. If the disks should not be mounted 
> why is there such a great performance difference ?

because when mounted rawio uses a blocksize larger than the
softblocksize (for no good reason, but that's another issue).

in short when the disk is mouned a single bh was doing I/O on a page (I
guess you were using 4k blocksize in the fs), while when it was
unmounted it was doing I/O on only 512bytes, so you needed 8 times more
bh and CPU to do the same I/O. 

there are many ways to fix this, I guess it would be nice to get the bio
stuff optimized in 2.5 first (bio will be even faster than your rawio
with the fs mounted, because a single metadata entity will be able to do
I/O on more than one page, that's the whole point of the bio design
changes). Then in 2.5 rawio can also be obsoleted and modularized.
O_DIRECT will have to relax its granularity requirements for both fs and
blkdev and so then it will overlap enterely the rawio chardevice
functionality.

btw, if you try to use O_DIRECT on the fs with your current kernel, you
should be just able to read at 340mbyte/sec with most of the CPU idle.

Andrea

  reply	other threads:[~2001-12-20 17:06 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-20 12:22 raw devices simon
2001-12-20 17:05 ` Andrea Arcangeli [this message]
2001-12-21  7:26 ` simon

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=20011220180547.C1395@athlon.random \
    --to=andrea@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=simon@baydel.com \
    /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.