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 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.