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
next prev parent 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