Re: [PATCH][RFC] dynamic pipe resizing - Kernel

This is a discussion on Re: [PATCH][RFC] dynamic pipe resizing - Kernel ; On Aug 24 2007 10:52, Jens Axboe wrote: >Subject: [PATCH][RFC] dynamic pipe resizing > >Hi, > >Dabbling around with splice a bit, I added some code to change the size >of a pipe. Currently it's hardcoded as 16 pages, with ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: [PATCH][RFC] dynamic pipe resizing

  1. Re: [PATCH][RFC] dynamic pipe resizing


    On Aug 24 2007 10:52, Jens Axboe wrote:
    >Subject: [PATCH][RFC] dynamic pipe resizing
    >
    >Hi,
    >
    >Dabbling around with splice a bit, I added some code to change the size
    >of a pipe. Currently it's hardcoded as 16 pages, with this patch you can
    >shrink (if you wanted) or grow (the likely scenario) if you want to
    >increase the size of your in-kernel buffer for splice operations.
    >
    >Like with my original splice patches from 2005, I used fcntl()
    >F_GETPIPE_SZ and F_SETPIPE_SZ to change the size of the pipe. I'm not
    >particularly fond of that interface, so suggestions on how to improve it
    >would be appreciated. Even if fcntl() should be the preferred approach,
    >I think it would be better to pass in a byte based value instead of a
    >number of pages.
    >

    Could this patch still make it in?
    Yes, I think its set() and get() parts should use bytes and convert
    to/from pages.

    > /*
    >+ * Allocate a new array of pipe buffers and copy the info over. Returns the
    >+ * pipe size if successful, or return -ERROR on error.
    >+ */
    >+static long pipe_set_size(struct pipe_inode_info *pipe, unsigned long arg)
    >+{
    >+ struct pipe_buffer *bufs;
    >+
    >+ /*
    >+ * Must be a power-of-2 current
    >+ */
    >+ if (arg & (arg - 1))
    >+ return -EINVAL;
    >+


    Perhaps just round up, and mention the rounding in the manpage, so that
    noone gets a shock when the pipe is not exactly as small as requested.

    >+ /*
    >+ * We can shrink the pipe, if arg >= pipe->nrbufs. Since we don't
    >+ * expect a lot of shrink+grow operations, just free and allocate
    >+ * again like we would do for growing. If the pipe currently
    >+ * contains more buffers than arg, then return busy.
    >+ */
    >+ if (arg < pipe->nrbufs)
    >+ return -EBUSY;


    How big can a pipe become? k*alloc has a certain limit, so should
    perhaps vmalloc be used for when kalloc fails?

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

  2. Re: [PATCH][RFC] dynamic pipe resizing

    On Saturday 15 December 2007, Jan Engelhardt wrote:
    > On Aug 24 2007 10:52, Jens Axboe wrote:
    > >Subject: [PATCH][RFC] dynamic pipe resizing
    > >Like with my original splice patches from 2005, I used fcntl()
    > >F_GETPIPE_SZ and F_SETPIPE_SZ to change the size of the pipe. I'm not
    > >particularly fond of that interface, so suggestions on how to improve it
    > >would be appreciated. Even if fcntl() should be the preferred approach,
    > >I think it would be better to pass in a byte based value instead of a
    > >number of pages.
    > >

    > Could this patch still make it in?
    > Yes, I think its set() and get() parts should use bytes and convert
    > to/from pages.
    >
    > Perhaps just round up, and mention the rounding in the manpage, so that
    > noone gets a shock when the pipe is not exactly as small as requested.


    Yes, but document only that it is rounding and make the unit arbitrary.
    That reduces the ABI requirements.


    Best Regards

    Ingo Oeser
    --
    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/

+ Reply to Thread