1. 25 7月, 2020 2 次提交
  2. 27 6月, 2020 1 次提交
  3. 15 6月, 2020 3 次提交
  4. 11 6月, 2020 3 次提交
  5. 09 6月, 2020 1 次提交
  6. 04 4月, 2020 1 次提交
  7. 24 3月, 2020 1 次提交
    • P
      io-wq: handle hashed writes in chains · 86f3cd1b
      Pavel Begunkov 提交于
      We always punt async buffered writes to an io-wq helper, as the core
      kernel does not have IOCB_NOWAIT support for that. Most buffered async
      writes complete very quickly, as it's just a copy operation. This means
      that doing multiple locking roundtrips on the shared wqe lock for each
      buffered write is wasteful. Additionally, buffered writes are hashed
      work items, which means that any buffered write to a given file is
      serialized.
      
      Keep identicaly hashed work items contiguously in @wqe->work_list, and
      track a tail for each hash bucket. On dequeue of a hashed item, splice
      all of the same hash in one go using the tracked tail. Until the batch
      is done, the caller doesn't have to synchronize with the wqe or worker
      locks again.
      Signed-off-by: NPavel Begunkov <asml.silence@gmail.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      86f3cd1b
  8. 23 3月, 2020 1 次提交
  9. 15 3月, 2020 3 次提交
  10. 12 3月, 2020 1 次提交
  11. 05 3月, 2020 4 次提交
  12. 03 3月, 2020 4 次提交
  13. 02 3月, 2020 1 次提交
  14. 25 2月, 2020 1 次提交
    • J
      io-wq: remove spin-for-work optimization · 3030fd4c
      Jens Axboe 提交于
      Andres reports that buffered IO seems to suck up more cycles than we
      would like, and he narrowed it down to the fact that the io-wq workers
      will briefly spin for more work on completion of a work item. This was
      a win on the networking side, but apparently some other cases take a
      hit because of it. Remove the optimization to avoid burning more CPU
      than we have to for disk IO.
      Reported-by: NAndres Freund <andres@anarazel.de>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      3030fd4c
  15. 13 2月, 2020 1 次提交
    • J
      io-wq: don't call kXalloc_node() with non-online node · 7563439a
      Jens Axboe 提交于
      Glauber reports a crash on init on a box he has:
      
       RIP: 0010:__alloc_pages_nodemask+0x132/0x340
       Code: 18 01 75 04 41 80 ce 80 89 e8 48 8b 54 24 08 8b 74 24 1c c1 e8 0c 48 8b 3c 24 83 e0 01 88 44 24 20 48 85 d2 0f 85 74 01 00 00 <3b> 77 08 0f 82 6b 01 00 00 48 89 7c 24 10 89 ea 48 8b 07 b9 00 02
       RSP: 0018:ffffb8be4d0b7c28 EFLAGS: 00010246
       RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000e8e8
       RDX: 0000000000000000 RSI: 0000000000000002 RDI: 0000000000002080
       RBP: 0000000000012cc0 R08: 0000000000000000 R09: 0000000000000002
       R10: 0000000000000dc0 R11: ffff995c60400100 R12: 0000000000000000
       R13: 0000000000012cc0 R14: 0000000000000001 R15: ffff995c60db00f0
       FS:  00007f4d115ca900(0000) GS:ffff995c60d80000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 0000000000002088 CR3: 00000017cca66002 CR4: 00000000007606e0
       DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
       DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
       PKRU: 55555554
       Call Trace:
        alloc_slab_page+0x46/0x320
        new_slab+0x9d/0x4e0
        ___slab_alloc+0x507/0x6a0
        ? io_wq_create+0xb4/0x2a0
        __slab_alloc+0x1c/0x30
        kmem_cache_alloc_node_trace+0xa6/0x260
        io_wq_create+0xb4/0x2a0
        io_uring_setup+0x97f/0xaa0
        ? io_remove_personalities+0x30/0x30
        ? io_poll_trigger_evfd+0x30/0x30
        do_syscall_64+0x5b/0x1c0
        entry_SYSCALL_64_after_hwframe+0x44/0xa9
       RIP: 0033:0x7f4d116cb1ed
      
      which is due to the 'wqe' and 'worker' allocation being node affine.
      But it isn't valid to call the node affine allocation if the node isn't
      online.
      
      Setup structures for even offline nodes, as usual, but skip them in
      terms of thread setup to not waste resources. If the node isn't online,
      just alloc memory with NUMA_NO_NODE.
      Reported-by: NGlauber Costa <glauber@scylladb.com>
      Tested-by: NGlauber Costa <glauber@scylladb.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      7563439a
  16. 10 2月, 2020 2 次提交
  17. 09 2月, 2020 1 次提交
  18. 30 1月, 2020 1 次提交
    • J
      io_uring: fix linked command file table usage · f86cd20c
      Jens Axboe 提交于
      We're not consistent in how the file table is grabbed and assigned if we
      have a command linked that requires the use of it.
      
      Add ->file_table to the io_op_defs[] array, and use that to determine
      when to grab the table instead of having the handlers set it if they
      need to defer. This also means we can kill the IO_WQ_WORK_NEEDS_FILES
      flag. We always initialize work->files, so io-wq can just check for
      that.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      f86cd20c
  19. 29 1月, 2020 2 次提交
  20. 28 1月, 2020 1 次提交
  21. 21 1月, 2020 2 次提交
    • J
      io-wq: support concurrent non-blocking work · 895e2ca0
      Jens Axboe 提交于
      io-wq assumes that work will complete fast (and not block), so it
      doesn't create a new worker when work is enqueued, if we already have
      at least one worker running. This is done on the assumption that if work
      is running, then it will complete fast.
      
      Add an option to force io-wq to fork a new worker for work queued. This
      is signaled by setting IO_WQ_WORK_CONCURRENT on the work item. For that
      case, io-wq will create a new worker, even though workers are already
      running.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      895e2ca0
    • J
      io-wq: add support for uncancellable work · 0c9d5ccd
      Jens Axboe 提交于
      Not all work can be cancelled, some of it we may need to guarantee
      that it runs to completion. Allow the caller to set IO_WQ_WORK_NO_CANCEL
      on work that must not be cancelled. Note that the caller work function
      must also check for IO_WQ_WORK_NO_CANCEL on work that is marked
      IO_WQ_WORK_CANCEL.
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      0c9d5ccd
  22. 15 1月, 2020 1 次提交
  23. 25 12月, 2019 1 次提交
  24. 23 12月, 2019 1 次提交