From: Andrew Morton <akpm@zip.com.au>
To: Stephen Lord <lord@sgi.com>
Cc: Jens Axboe <axboe@suse.de>, Andi Kleen <ak@suse.de>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] only irq-safe atomic ops
Date: Mon, 25 Feb 2002 11:42:21 -0800 [thread overview]
Message-ID: <3C7A939D.FCAE9096@zip.com.au> (raw)
In-Reply-To: <1014449389.1003.149.camel@phantasy.suse.lists.linux.kernel> <3C774AC8.5E0848A2@zip.com.au.suse.lists.linux.kernel> <3C77F503.1060005@sgi.com.suse.lists.linux.kernel> <p73y9hjq5mw.fsf@oldwotan.suse.de> <3C78045C.668AB945@zip.com.au> <3C780702.9060109@sgi.com> <3C780CDA.FEAF9CB4@zip.com.au> <3C781362.7070103@sgi.com> <3C781909.F69D8791@zip.com.au> <3C7A35FF.5040508@sgi.com> <20020225131218.GO11837@suse.de> <3C7A398A.1060300@sgi.com>
Stephen Lord wrote:
>
> Yep, bio just made it easier to get larger requests.
>
Which promptly go kersplat when you feed them into
submit_bio():
BUG_ON(bio_sectors(bio) > q->max_sectors);
Given that I'm hand-rolling a monster bio, I need to know
when to wrap it up and send it off, to avoid creating a bio
which is larger than the target device will accept. I'm currently
using the below patch. Am I right that this is missing API
functionality, or did I miss something?
Also, I could not find a way of querying the size of the vector
at *bi_io_vec. This is also information which would be helpful
when building large scatter/gather lists.
--- 2.5.5/drivers/block/ll_rw_blk.c~mpio-10-biobits Mon Feb 25 00:28:21 2002
+++ 2.5.5-akpm/drivers/block/ll_rw_blk.c Mon Feb 25 00:28:21 2002
@@ -1350,6 +1350,28 @@ static void end_bio_bh_io_sync(struct bi
}
/**
+ * bio_max_bytes: return the maximum number of bytes which can be
+ * placed in a single bio for a particular device.
+ *
+ * @dev: the device's kdev_t
+ *
+ * Each device has a maximum permissible queue size, and bios may
+ * not cover more data than that.
+ *
+ * Returns -ve on error.
+ */
+int bio_max_bytes(kdev_t dev)
+{
+ request_queue_t *q;
+ int ret = -1;
+
+ q = blk_get_queue(dev);
+ if (q)
+ ret = (q->max_sectors << 9);
+ return ret;
+}
+
+/**
* submit_bio: submit a bio to the block device layer for I/O
* @rw: whether to %READ or %WRITE, or maybe to %READA (read ahead)
* @bio: The &struct bio which describes the I/O
--- 2.5.5/include/linux/bio.h~mpio-10-biobits Mon Feb 25 00:28:21 2002
+++ 2.5.5-akpm/include/linux/bio.h Mon Feb 25 00:28:21 2002
@@ -204,5 +204,6 @@ extern struct bio *bio_copy(struct bio *
extern inline void bio_init(struct bio *);
extern int bio_ioctl(kdev_t, unsigned int, unsigned long);
+extern int bio_max_bytes(kdev_t dev);
#endif /* __LINUX_BIO_H */
-
next prev parent reply other threads:[~2002-02-25 19:44 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1014444810.1003.53.camel@phantasy.suse.lists.linux.kernel>
[not found] ` <3C773C02.93C7753E@zip.com.au.suse.lists.linux.kernel>
[not found] ` <1014449389.1003.149.camel@phantasy.suse.lists.linux.kernel>
[not found] ` <3C774AC8.5E0848A2@zip.com.au.suse.lists.linux.kernel>
[not found] ` <3C77F503.1060005@sgi.com.suse.lists.linux.kernel>
[not found] ` <3C77FB35.16844FE7@zip.com.au.suse.lists.linux.kernel>
2002-02-23 20:56 ` [PATCH] only irq-safe atomic ops Andi Kleen
2002-02-23 21:06 ` Andrew Morton
2002-02-23 21:17 ` Stephen Lord
2002-02-23 21:42 ` Andrew Morton
2002-02-23 22:10 ` Stephen Lord
2002-02-23 22:34 ` Andrew Morton
2002-02-23 23:07 ` Mike Fedyk
2002-02-23 23:47 ` Andrew Morton
2002-02-25 13:02 ` Stephen Lord
2002-02-25 13:12 ` Jens Axboe
2002-02-25 13:18 ` Stephen Lord
2002-02-25 19:42 ` Andrew Morton [this message]
2002-02-25 19:45 ` Steve Lord
2002-02-25 20:05 ` Andrew Morton
2002-02-23 6:13 Robert Love
2002-02-23 6:51 ` Andrew Morton
2002-02-23 7:29 ` Robert Love
2002-02-23 7:54 ` Andrew Morton
2002-02-23 11:38 ` yodaiken
2002-02-23 18:20 ` Robert Love
2002-02-23 19:06 ` yodaiken
2002-02-23 21:57 ` Roman Zippel
2002-02-23 22:10 ` Andrew Morton
2002-02-23 22:23 ` yodaiken
2002-02-23 22:40 ` Andrew Morton
2002-02-23 22:48 ` yodaiken
2002-02-23 23:13 ` Robert Love
2002-02-23 23:45 ` Robert Love
2002-02-23 23:56 ` Andrew Morton
2002-02-24 1:05 ` yodaiken
2002-02-24 1:08 ` Robert Love
2002-02-23 22:00 ` John Levon
2002-02-23 22:43 ` yodaiken
2002-02-23 20:01 ` Stephen Lord
2002-02-23 20:27 ` Andrew Morton
2002-02-23 9:38 ` Russell King
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=3C7A939D.FCAE9096@zip.com.au \
--to=akpm@zip.com.au \
--cc=ak@suse.de \
--cc=axboe@suse.de \
--cc=linux-kernel@vger.kernel.org \
--cc=lord@sgi.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