lkml.org 
[lkml]   [2007]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [00/17] Large Blocksize Support V3
    On Mon, May 07, 2007 at 12:06:38AM -0700, William Lee Irwin III wrote:
    > +int alloc_page_array(struct pagearray *, const int, const size_t);
    > +void free_page_array(struct pagearray *);
    > +void zero_page_array(struct pagearray *);
    > +struct page *nopage_page_array(const struct vm_area_struct *, unsigned long, unsigned long, int *, struct pagearray *);
    > +int mmap_page_array(const struct vm_area_struct *, struct pagearray *, const size_t, const size_t);
    > +int copy_page_array_to_user(struct pagearray *, void __user *, const size_t, const size_t);
    > +int copy_page_array_from_user(struct pagearray *, void __user *, const size_t, const size_t);
    > +struct scatterlist *pagearray_to_scatterlist(struct pagearray *, size_t, size_t, int *);
    > +void *vmap_pagearray(struct pagearray *);

    This should probably have memcpy to/from pagearrays. Whole-hog read
    and write f_op implementations would be good, too, since ISTR some
    drivers basically do little besides that on their internal buffers.

    vmap_pagearray() should take flags, esp. VM_IOREMAP but perhaps also
    protections besides PAGE_KERNEL in case uncachedness is desirable. I'm
    not entirely sure what it'd be used for if discontiguity is so heavily
    supported. My wild guess is drivers that do things that are just too
    weird to support with the discontig API, since that's how I used it.
    It should support vmap()'ing interior sub-ranges, too.

    The pagearray mmap() support is schizophrenic as to whether it prefills
    or faults and not all that complete as far as manipulating the mmap()
    goes. Shooting down ptes, flipping pages, or whatever drivers actually
    do with the things should have helpers arranged. Coherent sets of
    helpers for faulting vs. mmap()'ing idioms would be good.

    pagearray_to_scatterlist() should probably take the scatterist as an
    argument instead of allocating the scatterlist itself.

    Something to construct bio's from pagearrays might help.

    s/page_array/pagearray/g should probably be done. Prefixing with
    pagearray_ instead of randomly positioning it within the name would
    be good, too.

    Some working API conversions on drivers sound like a good idea. I had
    some large number of API conversions about, now lost, but they'd be
    bitrotted anyway.

    struct pagearray is better off as an opaque type so large pagearray
    handling can be added in later via radix trees or some such, likewise
    for expansion and contraction. Keeping drivers' hands off the internals
    is just a good idea in general.

    I'm somewhat less clear on what filesystems need to do here, or if it
    would be useful for them to efficiently manipulate data inside a
    large block that spans multiple discontiguous pages. I expect some
    changes are needed at the very least to fill a pagearray with whatever
    predetermined pages are needed. Filesystems probably need other changes
    to handle sparse pagearrays and refilling pages within them via IO.


    -- wli
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-05-08 10:53    [W:4.731 / U:0.016 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site