[lkml]   [2006]   [Feb]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Patch in this message
    SubjectRe: [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...)



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

    --- 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
    More majordomo info at
    Please read the FAQ at
     \ /
      Last update: 2006-02-23 02:46    [W:0.023 / U:0.928 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site