From: "Jeff V. Merkey" <jmerkey@drdos.com>
To: Jens Axboe <axboe@suse.de>
Cc: linux-kernel@vger.kernel.org, jmerkey@comcast.net
Subject: Re: 2.6.9-rc2 bio sickness with large writes
Date: Thu, 16 Sep 2004 10:38:14 -0600 [thread overview]
Message-ID: <4149C176.2020506@drdos.com> (raw)
In-Reply-To: <20040916063416.GI2300@suse.de>
>
>>static int end_bio_asynch(struct bio *bio, unsigned int bytes_done, int err)
>>{
>> ASYNCH_IO *io = bio->bi_private;
>>
>>
>>
>
> if (bio->bi_size)
> return 1;
>
>
I guess the question here is if a group of coalesed bios are submitted,
shouldn't I get a callback
on each one? This implies if they merge beneath me, I won't always see
the callback for each one.
Is this an acuurate assumption?
>
>
>> register struct page *page = virt_to_page(&Sector[i * blocksize]);
>> register ULONG offset = ((ULONG)(&Sector[i * blocksize])) % PAGE_SIZE;
>> register ULONG bytes;
>>
>> bytes = bio_add_page(io->bio, page,
>> PAGE_SIZE - (offset % PAGE_SIZE), 0);
>>
>>
>
>offset instead of 0?
>
>
>
blocksize always = PAGE_SIZE in this code. PAGE_SIZE - (offset %
PAGE_SIZE) determines the length of the
transfer. You could just as well substitute PAGE_SIZE for blocksize. I
always set the device (if it supports it) to a
PAGE_SIZE for the blocksize. 1024 blocksize is a little small.
>Get rid of this if/else, it's not correct. 2.6 always had
>bio_add_page(), and you _must_ use it.
>
>
>
Linus should then do the same in buffer.c since this example is
misleading in the code. Linus seems to get away with it
so why can't I? :-)
buffer.c line 2776
/*
* from here on down, it's all bio -- do the initial mapping,
* submit_bio -> generic_make_request may further map this bio around
*/
bio = bio_alloc(GFP_NOIO, 1);
bio->bi_sector = bh->b_blocknr * (bh->b_size >> 9);
bio->bi_bdev = bh->b_bdev;
bio->bi_io_vec[0].bv_page = bh->b_page;
bio->bi_io_vec[0].bv_len = bh->b_size;
bio->bi_io_vec[0].bv_offset = bh_offset(bh);
bio->bi_vcnt = 1;
bio->bi_idx = 0;
bio->bi_size = bh->b_size;
bio->bi_end_io = end_bio_bh_io_sync;
bio->bi_private = bh;
submit_bio(rw, bio);
>> // unplug the queue and drain the bathtub
>> bio_get(io->bio);
>> submit_bio(WRITE | (1 << BIO_RW_SYNC), io->bio);
>> bio_put(io->bio);
>>
>>
>
>You don't get to get/put the bio here, you aren't touching it after
>submit_bio().
>
>
>
I removed this from my code. You need to correct the example in bio.h
with something more meaningful. This is what
the source code says to do.
bio.h line 213
/*
* get a reference to a bio, so it won't disappear. the intended use is
* something like: *
* bio_get(bio);
* submit_bio(rw, bio);
* if (bio->bi_flags ...)
* do_something
* bio_put(bio);
*
* without the bio_get(), it could potentially complete I/O before submit_bio
* returns. and then bio would be freed memory when if (bio->bi_flags ...)
* runs
*/
I still see the problem and I suspect it's related to the callback
mechanism with the bio-bi_size check always returning 1. I guess
the question here is are bios guaranteed to always return a 1:1 ratio of
submission vs. callbacks?
Jeff
next prev parent reply other threads:[~2004-09-16 17:19 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-15 23:39 2.6.9-rc2 bio sickness with large writes Jeff V. Merkey
2004-09-16 6:34 ` Jens Axboe
2004-09-16 16:38 ` Jeff V. Merkey [this message]
2004-09-17 7:36 ` Jens Axboe
[not found] ` <20040917201604.GA12974@galt.devicelogics.com>
2004-09-20 17:12 ` Jeff V. Merkey
2004-09-20 18:09 ` Jens Axboe
2004-09-20 19:20 ` Jeff V. Merkey
2004-09-21 6:40 ` Jens Axboe
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=4149C176.2020506@drdos.com \
--to=jmerkey@drdos.com \
--cc=axboe@suse.de \
--cc=jmerkey@comcast.net \
--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