From: Jens Axboe <axboe@suse.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Cc: Simon Haynes <simon@baydel.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: SFFDC and blksize_size
Date: Mon, 10 Nov 2003 15:23:41 +0100 [thread overview]
Message-ID: <20031110142341.GG32637@suse.de> (raw)
In-Reply-To: <1068473878.5743.6.camel@hades.cambridge.redhat.com>
On Mon, Nov 10 2003, David Woodhouse wrote:
> On Mon, 2003-11-10 at 15:09 +0100, Jens Axboe wrote:
> > On Fri, Nov 07 2003, Simon Haynes wrote:
> > >
> > > I have been writing a block driver for SSFDC compliant SMC cards. This stuff
> > > allocates 16k blocks. When I get requests the transfers are split into the
> > > size I specifty in the blksize_size{MAJOR] array. It sems that most things
> >
> > Sounds like a bad way to do it. It's much better to prevent builds of
> > bigger requests than you can handle in one go. You don't mention what
> > kernel you are using, but both 2.4 and 2.6 can do this for you.
>
> The problem is the other way round -- he wants request merging, and he's
> achieving this by setting the block size higher.... and observing a
> crash when he sets his block size higher than PAGE_SIZE.
Yes I know, but he doesn't want requests merged > 16k, right? So it's
stupid to allow these to get through.
--
Jens Axboe
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@suse.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: Simon Haynes <simon@baydel.com>,
linux-mtd@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: SFFDC and blksize_size
Date: Mon, 10 Nov 2003 15:23:41 +0100 [thread overview]
Message-ID: <20031110142341.GG32637@suse.de> (raw)
In-Reply-To: <1068473878.5743.6.camel@hades.cambridge.redhat.com>
On Mon, Nov 10 2003, David Woodhouse wrote:
> On Mon, 2003-11-10 at 15:09 +0100, Jens Axboe wrote:
> > On Fri, Nov 07 2003, Simon Haynes wrote:
> > >
> > > I have been writing a block driver for SSFDC compliant SMC cards. This stuff
> > > allocates 16k blocks. When I get requests the transfers are split into the
> > > size I specifty in the blksize_size{MAJOR] array. It sems that most things
> >
> > Sounds like a bad way to do it. It's much better to prevent builds of
> > bigger requests than you can handle in one go. You don't mention what
> > kernel you are using, but both 2.4 and 2.6 can do this for you.
>
> The problem is the other way round -- he wants request merging, and he's
> achieving this by setting the block size higher.... and observing a
> crash when he sets his block size higher than PAGE_SIZE.
Yes I know, but he doesn't want requests merged > 16k, right? So it's
stupid to allow these to get through.
--
Jens Axboe
next prev parent reply other threads:[~2003-11-10 14:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-07 13:12 SFFDC and blksize_size Simon Haynes
2003-11-07 14:18 ` David Woodhouse
2003-11-07 14:18 ` David Woodhouse
2003-11-10 14:09 ` Jens Axboe
2003-11-10 14:09 ` Jens Axboe
2003-11-10 14:17 ` David Woodhouse
2003-11-10 14:17 ` David Woodhouse
2003-11-10 14:23 ` Jens Axboe [this message]
2003-11-10 14:23 ` 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=20031110142341.GG32637@suse.de \
--to=axboe@suse.de \
--cc=dwmw2@infradead.org \
--cc=linux-mtd@lists.infradead.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.