From: arjan@fenrus.demon.nl
To: pbadari@us.ibm.com (Badari Pulavarty)
Cc: linux-kernel@vger.kernel.org
Subject: Re: patch: aio + bio for raw io
Date: Fri, 8 Feb 2002 21:18:05 +0000 (GMT) [thread overview]
Message-ID: <m16ZIPF-000OVeC@amadeus.home.nl> (raw)
In-Reply-To: <200202082107.g18L7wx26206@eng2.beaverton.ibm.com>
In article <200202082107.g18L7wx26206@eng2.beaverton.ibm.com> you wrote:
> 1) brw_kvec_async() does not seem to split IO at BIO_MAX_SIZE. I thought
> each bio can handle only BIO_MAX_SIZE (ll_rw_kio() is creating one bio
> for each BIO_MAX_SIZE IO).
> And also, currently BIO_MAX_SIZE is only 64K. Infact, if I try to issue
> 64K IO using submit_bio(), I get following BUG() on my QLOGIC controller.
> kernel BUG at ll_rw_blk.c:1336
> Code is: BUG_ON(bio_sectors(bio) > q->max_sectors);
> bio_sectors(bio) is 128
> q->max_sectors is 64 (for QLOGIC ISP)
this is a bio bug. BIO should split if needed.
(Oh and qlogic hw can easily handle 1024 sector-sized requests)
> 2) Could you please make map_user_kvec() generic enough to handle mapping
> of mutliple iovecs to single kvec (to handle readv/writev).
I think the "move all readv/writev to one single kvec" is a mistake. The
OPPOSITE should happen. If you submit a huge single vector it should be
split up internally. This would also be the fix for the "submit the entire
vector so far and sync wait on it after 512Kb" performance bug in the normal
rawio code, since it can just submit partial (say 256Kb sized) vectors and
wait for ANY one of them before going over a 512Kb boundary.
Sure readv/writev are not optimal now. but that is because the kernel waits for
IO complete per vector element instead of submitting them all async and
waiting at the end (or in the aio case, not wait at all).
Gretings,
Arjan van de Ven.
next prev parent reply other threads:[~2002-02-08 21:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-08 7:53 patch: aio + bio for raw io Benjamin LaHaise
2002-02-08 9:40 ` Suparna Bhattacharya
2002-02-08 22:02 ` Benjamin LaHaise
2002-02-11 18:11 ` Suparna Bhattacharya
2002-02-08 21:07 ` Badari Pulavarty
2002-02-08 21:18 ` arjan [this message]
2002-02-08 22:13 ` Benjamin LaHaise
2002-02-08 22:54 ` Linus Torvalds
[not found] ` <200202082254.g18Mspq08299@penguin.transmeta.com>
2002-02-09 0:01 ` Benjamin LaHaise
2002-02-09 0:25 ` Linus Torvalds
2002-02-14 4:46 ` Suparna Bhattacharya
2002-02-11 11:09 ` Jens Axboe
2002-02-11 21:37 ` 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=m16ZIPF-000OVeC@amadeus.home.nl \
--to=arjan@fenrus.demon.nl \
--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