1. 02 5月, 2006 3 次提交
    • J
      [PATCH] pipe: enable atomic copying of pipe data to/from user space · f6762b7a
      Jens Axboe 提交于
      The pipe ->map() method uses kmap() to virtually map the pages, which
      is both slow and has known scalability issues on SMP. This patch enables
      atomic copying of pipe pages, by pre-faulting data and using kmap_atomic()
      instead.
      
      lmbench bw_pipe and lat_pipe measurements agree this is a Good Thing. Here
      are results from that on a UP machine with highmem (1.5GiB of RAM), running
      first a UP kernel, SMP kernel, and SMP kernel patched.
      
      Vanilla-UP:
      Pipe bandwidth: 1622.28 MB/sec
      Pipe bandwidth: 1610.59 MB/sec
      Pipe bandwidth: 1608.30 MB/sec
      Pipe latency: 7.3275 microseconds
      Pipe latency: 7.2995 microseconds
      Pipe latency: 7.3097 microseconds
      
      Vanilla-SMP:
      Pipe bandwidth: 1382.19 MB/sec
      Pipe bandwidth: 1317.27 MB/sec
      Pipe bandwidth: 1355.61 MB/sec
      Pipe latency: 9.6402 microseconds
      Pipe latency: 9.6696 microseconds
      Pipe latency: 9.6153 microseconds
      
      Patched-SMP:
      Pipe bandwidth: 1578.70 MB/sec
      Pipe bandwidth: 1579.95 MB/sec
      Pipe bandwidth: 1578.63 MB/sec
      Pipe latency: 9.1654 microseconds
      Pipe latency: 9.2266 microseconds
      Pipe latency: 9.1527 microseconds
      Signed-off-by: NJens Axboe <axboe@suse.de>
      f6762b7a
    • J
      [PATCH] pipe: introduce ->pin() buffer operation · f84d7519
      Jens Axboe 提交于
      The ->map() function is really expensive on highmem machines right now,
      since it has to use the slower kmap() instead of kmap_atomic(). Splice
      rarely needs to access the virtual address of a page, so it's a waste
      of time doing it.
      
      Introduce ->pin() to take over the responsibility of making sure the
      page data is valid. ->map() is then reduced to just kmap(). That way we
      can also share a most of the pipe buffer ops between pipe.c and splice.c
      Signed-off-by: NJens Axboe <axboe@suse.de>
      f84d7519
    • J
      [PATCH] splice: fix bugs in pipe_to_file() · 0568b409
      Jens Axboe 提交于
      Found by Oleg Nesterov <oleg@tv-sign.ru>, fixed by me.
      
      - Only allow full pages to go to the page cache.
      - Check page != buf->page instead of using PIPE_BUF_FLAG_STOLEN.
      - Remember to clear 'stolen' if add_to_page_cache() fails.
      
      And as a cleanup on that:
      
      - Make the bottom fall-through logic a little less convoluted. Also make
        the steal path hold an extra reference to the page, so we don't have
        to differentiate between stolen and non-stolen at the end.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      0568b409
  2. 30 4月, 2006 1 次提交
  3. 11 4月, 2006 5 次提交
  4. 10 4月, 2006 1 次提交
    • I
      [PATCH] introduce a "kernel-internal pipe object" abstraction · 3a326a2c
      Ingo Molnar 提交于
      separate out the 'internal pipe object' abstraction, and make it
      usable to splice. This cleans up and fixes several aspects of the
      internal splice APIs and the pipe code:
      
       - pipes: the allocation and freeing of pipe_inode_info is now more symmetric
         and more streamlined with existing kernel practices.
      
       - splice: small micro-optimization: less pointer dereferencing in splice
         methods
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      
      Update XFS for the ->splice_read/->splice_write changes.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      3a326a2c
  5. 03 4月, 2006 2 次提交
  6. 31 3月, 2006 2 次提交
    • J
      [PATCH] splice: add support for SPLICE_F_MOVE flag · 5abc97aa
      Jens Axboe 提交于
      This enables the caller to migrate pages from one address space page
      cache to another.  In buzz word marketing, you can do zero-copy file
      copies!
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5abc97aa
    • J
      [PATCH] Introduce sys_splice() system call · 5274f052
      Jens Axboe 提交于
      This adds support for the sys_splice system call. Using a pipe as a
      transport, it can connect to files or sockets (latter as output only).
      
      From the splice.c comments:
      
         "splice": joining two ropes together by interweaving their strands.
      
         This is the "extended pipe" functionality, where a pipe is used as
         an arbitrary in-memory buffer. Think of a pipe as a small kernel
         buffer that you can use to transfer data from one end to the other.
      
         The traditional unix read/write is extended with a "splice()" operation
         that transfers data buffers to or from a pipe buffer.
      
         Named by Larry McVoy, original implementation from Linus, extended by
         Jens to support splicing to files and fixing the initial implementation
         bugs.
      Signed-off-by: NJens Axboe <axboe@suse.de>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5274f052
  7. 29 3月, 2006 1 次提交
  8. 27 3月, 2006 1 次提交
  9. 26 3月, 2006 1 次提交
  10. 09 3月, 2006 1 次提交
  11. 15 1月, 2006 1 次提交
  12. 11 1月, 2006 1 次提交
  13. 10 1月, 2006 1 次提交
  14. 11 9月, 2005 1 次提交
    • I
      [PATCH] sched: TASK_NONINTERACTIVE · d79fc0fc
      Ingo Molnar 提交于
      This patch implements a task state bit (TASK_NONINTERACTIVE), which can be
      used by blocking points to mark the task's wait as "non-interactive".  This
      does not mean the task will be considered a CPU-hog - the wait will simply
      not have an effect on the waiting task's priority - positive or negative
      alike.  Right now only pipe_wait() will make use of it, because it's a
      common source of not-so-interactive waits (kernel compilation jobs, etc.).
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      d79fc0fc
  15. 08 9月, 2005 1 次提交
  16. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4