1. 29 6月, 2019 4 次提交
  2. 13 6月, 2019 1 次提交
  3. 12 6月, 2019 8 次提交
  4. 10 6月, 2019 1 次提交
  5. 04 6月, 2019 1 次提交
  6. 24 5月, 2019 1 次提交
  7. 21 5月, 2019 2 次提交
  8. 18 5月, 2019 1 次提交
  9. 02 5月, 2019 1 次提交
  10. 30 4月, 2019 4 次提交
  11. 27 4月, 2019 6 次提交
  12. 23 4月, 2019 7 次提交
  13. 17 4月, 2019 3 次提交
    • D
      xfs: merge adjacent io completions of the same type · 3994fc48
      Darrick J. Wong 提交于
      It's possible for pagecache writeback to split up a large amount of work
      into smaller pieces for throttling purposes or to reduce the amount of
      time a writeback operation is pending.  Whatever the reason, XFS can end
      up with a bunch of IO completions that call for the same operation to be
      performed on a contiguous extent mapping.  Since mappings are extent
      based in XFS, we'd prefer to run fewer transactions when we can.
      
      When we're processing an ioend on the list of io completions, check to
      see if the next items on the list are both adjacent and of the same
      type.  If so, we can merge the completions to reduce transaction
      overhead.
      
      On fast storage this doesn't seem to make much of a difference in
      performance, though the number of transactions for an overnight xfstests
      run seems to drop by ~5%.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      3994fc48
    • D
      xfs: remove unused m_data_workqueue · 28408243
      Darrick J. Wong 提交于
      Now that we're no longer using m_data_workqueue, remove it.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      28408243
    • D
      xfs: implement per-inode writeback completion queues · cb357bf3
      Darrick J. Wong 提交于
      When scheduling writeback of dirty file data in the page cache, XFS uses
      IO completion workqueue items to ensure that filesystem metadata only
      updates after the write completes successfully.  This is essential for
      converting unwritten extents to real extents at the right time and
      performing COW remappings.
      
      Unfortunately, XFS queues each IO completion work item to an unbounded
      workqueue, which means that the kernel can spawn dozens of threads to
      try to handle the items quickly.  These threads need to take the ILOCK
      to update file metadata, which results in heavy ILOCK contention if a
      large number of the work items target a single file, which is
      inefficient.
      
      Worse yet, the writeback completion threads get stuck waiting for the
      ILOCK while holding transaction reservations, which can use up all
      available log reservation space.  When that happens, metadata updates to
      other parts of the filesystem grind to a halt, even if the filesystem
      could otherwise have handled it.
      
      Even worse, if one of the things grinding to a halt happens to be a
      thread in the middle of a defer-ops finish holding the same ILOCK and
      trying to obtain more log reservation having exhausted the permanent
      reservation, we now have an ABBA deadlock - writeback completion has a
      transaction reserved and wants the ILOCK, and someone else has the ILOCK
      and wants a transaction reservation.
      
      Therefore, we create a per-inode writeback io completion queue + work
      item.  When writeback finishes, it can add the ioend to the per-inode
      queue and let the single worker item process that queue.  This
      dramatically cuts down on the number of kworkers and ILOCK contention in
      the system, and seems to have eliminated an occasional deadlock I was
      seeing while running generic/476.
      
      Testing with a program that simulates a heavy random-write workload to a
      single file demonstrates that the number of kworkers drops from
      approximately 120 threads per file to 1, without dramatically changing
      write bandwidth or pagecache access latency.
      
      Note that we leave the xfs-conv workqueue's max_active alone because we
      still want to be able to run ioend processing for as many inodes as the
      system can handle.
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NBrian Foster <bfoster@redhat.com>
      cb357bf3
反馈
建议
客服 返回
顶部