From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Alex Dubov <oakad@yahoo.com>
Cc: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>,
akpm@linux-foundation.org, maximlevitsky@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/4] scatterlist: new helper functions
Date: Wed, 16 Mar 2011 23:57:06 -0400 [thread overview]
Message-ID: <1300334226.2620.26.camel@mulgrave.site> (raw)
In-Reply-To: <722844.29100.qm@web37604.mail.mud.yahoo.com>
On Wed, 2011-03-16 at 20:46 -0700, Alex Dubov wrote:
> >
> > Why?
> >
> > Why can't the block layer split a request in the way the
> > driver wants
> > to do?
> >
> > That is, why can't the driver tell the block layer how to
> > split a
> > request?
>
> What is needed is the ability to get fixed sized (in bytes) blocks from
> the block layer.
>
> Last time I checked (it was a long time ago, admittedly) one could only
> ask for a fixed number of sg entries, without any control on how many
> bytes each sg entry references.
>
> Is there a way to get data from the block layer in a fashion of:
> "Give me 16k/32k/whatever in one sg entry if request is equal or larger
> than this"?
Yes; we've always had it: it's blk_max_queue_hw_sectors(). No request
will go over that number times the sector size (of course, they may go
under).
> If my knowledge is correct, MTD currently addresses this issue by
> maintaining its own cache, which it uses to aggregate write requests until
> it can write a whole erase block. While this is ok with old media
> (legacy memory stick being an example of such), new flash chips can
> have multi-megabyte sized erase blocks and can benefit from operations
> (like copy and compare) directly on scatter list .
So this is where you want a minimum too. What you likely want is to set
the logical block size to your erase block
(blk_queue_logical_block_size) and the physical block size to the actual
block size. Then we'll try as hard as we can to send down blocks on an
erase boundary. Of course, there are some that just won't fit (like fs
metadata) and you'll have to do a RMW for them.
James
next prev parent reply other threads:[~2011-03-17 3:57 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-04 4:16 [PATH 0/4] Memstick patches for 2.6.39 Maxim Levitsky
2011-03-04 4:16 ` [PATCH 1/4] scatterlist: new helper functions Maxim Levitsky
2011-03-06 7:29 ` FUJITA Tomonori
2011-03-06 15:14 ` Maxim Levitsky
2011-03-06 21:49 ` FUJITA Tomonori
2011-03-07 2:20 ` Maxim Levitsky
2011-03-09 17:24 ` Maxim Levitsky
2011-03-16 0:44 ` Andrew Morton
2011-03-16 2:35 ` FUJITA Tomonori
2011-03-16 4:18 ` Alex Dubov
2011-03-16 4:55 ` FUJITA Tomonori
2011-03-17 3:46 ` Alex Dubov
2011-03-17 3:57 ` James Bottomley [this message]
2011-03-16 22:33 ` Andrew Morton
2011-03-17 6:41 ` Alex Dubov
2011-03-17 13:17 ` Maxim Levitsky
2011-03-18 0:59 ` FUJITA Tomonori
2011-03-04 4:16 ` [PATCH 2/4] memstick: add support for legacy memorysticks Maxim Levitsky
2011-03-04 4:16 ` [PATCH 3/4] memstick: Add driver for Ricoh R5C592 card reader Maxim Levitsky
2011-03-16 4:25 ` Alex Dubov
2011-03-04 4:16 ` [PATCH 4/4] memstick: add Alex Dubov to MAINTAINERS of the memstick core Maxim Levitsky
2011-03-12 16:23 ` [PATH 0/4] Memstick patches for 2.6.39 Maxim Levitsky
2011-03-15 20:00 ` Maxim Levitsky
2011-03-15 21:04 ` Andrew Morton
2011-03-16 0:25 ` Maxim Levitsky
2011-03-20 3:09 ` Maxim Levitsky
2011-03-20 6:47 ` Andrew Morton
2011-03-20 11:42 ` Maxim Levitsky
2011-03-22 13:01 ` Maxim Levitsky
2011-03-22 23:21 ` Andrew Morton
2011-03-23 0:59 ` Maxim Levitsky
2011-03-23 3:42 ` Greg KH
2011-03-23 15:30 ` Maxim Levitsky
2011-03-24 3:27 ` Alex Dubov
-- strict thread matches above, loose matches on Subject: below --
2011-01-11 23:36 [PATCH V2 0/4]: MEMSTICK: My 2 drivers for 2.6.38 inclusion Maxim Levitsky
2011-01-11 23:36 ` [PATCH 1/4] scatterlist: new helper functions Maxim Levitsky
2011-01-11 23:51 ` Randy Dunlap
2011-01-11 23:55 ` Andrew Morton
2011-01-11 23:58 ` Randy Dunlap
2011-01-12 2:52 ` Maxim Levitsky
2011-01-12 6:41 ` Randy Dunlap
2011-01-11 2:58 Alex Dubov
2011-01-11 1:50 MEMSTICK: My 2 drivers for 2.6.38 inclusion Maxim Levitsky
2011-01-11 1:50 ` [PATCH 1/4] scatterlist: new helper functions Maxim Levitsky
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=1300334226.2620.26.camel@mulgrave.site \
--to=james.bottomley@hansenpartnership.com \
--cc=akpm@linux-foundation.org \
--cc=fujita.tomonori@lab.ntt.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=maximlevitsky@gmail.com \
--cc=oakad@yahoo.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;
as well as URLs for NNTP newsgroup(s).