public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Joel Becker <jlbec@evilplan.org>
To: Badari Pulavarty <pbadari@us.ibm.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PAGE_SIZE IO for RAW (RAW VARY)
Date: Tue, 15 Jan 2002 03:16:45 +0000	[thread overview]
Message-ID: <20020115031644.E1929@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <E16OlMo-0005NV-00@the-village.bc.nu> <200201102115.g0ALF1e28859@eng2.beaverton.ibm.com>
In-Reply-To: <200201102115.g0ALF1e28859@eng2.beaverton.ibm.com>; from pbadari@us.ibm.com on Thu, Jan 10, 2002 at 01:15:01PM -0800

On Thu, Jan 10, 2002 at 01:15:01PM -0800, Badari Pulavarty wrote:
> The issue with my (mostly) PAGE_SIZE RAW IO patch is, it could generate
> buffer heads with different b_size in a single IO request. Jens & Ben
> have concerns about some of the low level drivers not able to handle
> these. (it would be hard to analyse all the drivers to verify this).
> 
> So, Andrea suggested we add a flag in "blk_dev" structure. Only the
> drivers which support variable size buffer heads in a single IO will
> set it. My RAW VARY patch will use this flag to see if I can do 
> RAW VARY or not. Makes sense ?

	The way I handled it in my O_DIRECT code for the same task (do
the largest I/O you can, instead of a hardcoded 512 or sw_blocksize) was
to merely choose the minimum alignment.  See the patch in
<20020109195606.A16884@parcelfarce.linux.theplanet.co.uk>.  In your
approach, you want leading blocks to be aligned at 512 or so, then all
4k aligned I/Os to be 4k size, then the trailing I/Os are aligned again
at their size.  My approach was 'if aligned at 512, do all 512'.  It is
slower than your approach for large I/Os aligned on 512, but it also
has the property of submitting identical blocksizes in one request.
	Andrea has suggested that I work with you to be incremental on
top of your code.  This would include managing a flag bit to decide if a
device can handle variable I/O sizes in one request.  The issue I have
with that is that in the O_DIRECT case, the fallback is failure, not
slow I/O.  IOW, in rawio, if the flag is false, you issue all I/Os with
a 512 blocksize.  That's slow.  However, in O_DIRECT, if the flag is
false, the sw_blocksize is 4096, and the alignment is 512, you fail with
EINVAL.  That is bad.  In my current patch, the O_DIRECT I/O would
succeed at a 512 byte blocksize.  However, my patch doesn't touch rawio
at all.
	Please have a look at my patch and maybe we can work on merging
our efforts.

Joel

-- 

"The first thing we do, let's kill all the lawyers."
                                        -Henry VI, IV:ii

			http://www.jlbec.org/
			jlbec@evilplan.org

  reply	other threads:[~2002-01-15  3:17 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-09 17:41 [PATCH] PAGE_SIZE IO for RAW (RAW VARY) Badari Pulavarty
2002-01-09 17:58 ` Benjamin LaHaise
2002-01-09 18:12   ` Badari Pulavarty
2002-01-09 18:21     ` Benjamin LaHaise
2002-01-09 19:28       ` Badari Pulavarty
2002-01-09 19:49         ` Benjamin LaHaise
2002-01-09 22:58         ` Alan Cox
2002-01-09 23:48           ` Badari Pulavarty
2002-01-10 10:34             ` Andrea Arcangeli
2002-01-10 10:29           ` Andrea Arcangeli
2002-01-10 10:18         ` Andrea Arcangeli
2002-01-10 10:22           ` Jens Axboe
2002-01-10 10:47             ` Andrea Arcangeli
2002-01-10 10:51               ` Jens Axboe
2002-01-10 11:09                 ` Andrea Arcangeli
2002-01-10 16:58                   ` Badari Pulavarty
2002-01-11 13:52                     ` Andrea Arcangeli
2002-01-10 19:24                   ` Badari Pulavarty
2002-01-10 20:00                     ` Alan Cox
2002-01-10 21:03                       ` Badari Pulavarty
2002-01-10 21:26                         ` Alan Cox
2002-01-10 21:15                       ` Badari Pulavarty
2002-01-15  3:16                         ` Joel Becker [this message]
2002-01-10  7:12       ` Jens Axboe
2002-01-09 18:13   ` Jens Axboe
2002-01-09 22:56 ` Alan Cox
2002-01-09 23:20   ` Badari Pulavarty
2002-01-10  0:23     ` Alan Cox
2002-01-10  4:06       ` GOTO Masanori
     [not found] <200201091741.g09HfAI17240@eng2.beaverton.ibm.com.suse.lists.linux.kernel>
     [not found] ` <20020109125845.B12609@redhat.com.suse.lists.linux.kernel>
2002-01-09 18:15   ` Andi Kleen
     [not found] <200201102153.g0ALrl402482@eng2.beaverton.ibm.com>
2002-01-10 22:11 ` Alan Cox
2002-01-10 22:20   ` Badari Pulavarty

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=20020115031644.E1929@parcelfarce.linux.theplanet.co.uk \
    --to=jlbec@evilplan.org \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox