Re: [PATCH 0/3] map multiple blocks in get_block() and mpage_readpages()

On Wed, Feb 22, 2006 at 05:59:42PM +0100, christoph wrote:
On Wed, Feb 22, 2006 at 08:58:30AM -0800, Badari Pulavarty wrote:
Thanks. Only current issue Nathan raised is, he wants to see
b_size change to u64 [size_t] (instead of u32) to support
really-huge-IO requests.

And also to not go backwards on what the current DIO mapping
interface provides us.

Does this sound reasonable to you ?

I know that we didn't want to increase b_size at some point because
of concerns about the number of objects fitting into a page in the

There's four extra bytes on an 88 byte structure (with sector_t
CONFIG'd at 64 bits) - so, yes, there'll be a small decrease in
the number that fit in a page on 64 bit platforms. Perhaps its
not worth it, but it would be good to sort out these pesky size
mismatches cos they introduce very subtle bugs.

slab allocator. If the same number of bigger heads fit into the
same page I see no problems with the increase.

Heh, bigger heads. Well, the same number fit in the page for 32
bit platforms, does that count?

Taking a quick look at the struct definition, theres some oddities
crept in since the 2.4 version - looks like sct had arranged the
fields in nice 32-bit-platform-cache-aligned groups, with several
cache-alignment related comments, some of which now remain and make
very little sense on their own (& with the now-incorrect grouping).

Anyway, here's a patch Badari - I reckon its worth it, but then I
am a bit biased (as its likely only XFS is going to be seeing this
size of I/O for some time, and as someone who has hunted down some
of these size mismatch bugs...)

cheers.

--
Nathan


Increase the size of the buffer_head b_size field for 64 bit
platforms. Update some old and moldy comments in and around
the structure as well.

The b_size increase allows us to perform larger mappings and
allocations for large I/O requests from userspace, which tie
in with other changes allowing the get_block_t() interface to
map multiple blocks at once.

Signed-off-by: Nathan Scott <nathans@xxxxxxx>

--- a/include/linux/buffer_head.h
+++ b/include/linux/buffer_head.h
@@ -46,20 +46,25 @@ struct address_space;
typedef void (bh_end_io_t)(struct buffer_head *bh, int uptodate);

/*
- * Keep related fields in common cachelines. The most commonly accessed
- * field (b_state) goes at the start so the compiler does not generate
- * indexed addressing for it.
+ * Historically, a buffer_head was used to map a single block
+ * within a page, and of course as the unit of I/O through the
+ * filesystem and block layers. Nowadays the basic I/O unit
+ * is the bio, and buffer_heads are used for extracting block
+ * mappings (via a get_block_t call), for tracking state within
+ * a page (via a page_mapping) and for wrapping bio submission
+ * for backward compatibility reasons (e.g. submit_bh). There
+ * may be one or two other uses too (I used it for drying the
+ * dishes the other night when I couldn't find a tea towel...).
*/
struct buffer_head {
- /* First cache line: */
unsigned long b_state; /* buffer state bitmap (see above) */
struct buffer_head *b_this_page;/* circular list of page's buffers */
struct page *b_page; /* the page this bh is mapped to */
- atomic_t b_count; /* users using this block */
- u32 b_size; /* block size */
+ atomic_t b_count; /* users using this buffer_head */

- sector_t b_blocknr; /* block number */
- char *b_data; /* pointer to data block */
+ size_t b_size; /* size of mapping */
+ sector_t b_blocknr; /* start block number */
+ char *b_data; /* pointer to data within the page */

struct block_device *b_bdev;
bh_end_io_t *b_end_io; /* I/O completion */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: New "CP/M for Commodore" project
    ... none of these boards have a RS-232 interface. ... why not using the available I/O ... SSSL goes low, then the device get ready to respond. ... part into distinct segments, with one segment allocated as "Drive A", ...
    (comp.os.cpm)
  • best option for terminal emulation?
    ... to interface a MicroVGA adaptor (http://www.dontronics-shop.com/4d- ... So I need to work out what the command protocol will be betwen the I/O ... moving the cursor to a particular location etc. ... CURSOR (Cursor addressing sequence, sends cursor to ...
    (comp.os.cpm)
  • Re: aio_read/write versus O_NONBLOCK
    ... | rarely useful because 'I/O-cache' (page cache, block buffer cache) ... If what is intended does not include being able to overlap I/O in a consistent ... Creating a new interface designed to support ... interfaces should be completely uniform for everything I/O ever needs to ...
    (comp.unix.programmer)
  • Re: Firewire of PCI? I cant decide!
    ... "PCI is a pain in the ass" and "completely unnecessary for audio ... the firewire interface chips are PCI devices.. ... ADAT I/O. ...
    (rec.audio.pro)
Loading