1. 09 6月, 2021 1 次提交
  2. 03 6月, 2021 1 次提交
    • D
      xfs: don't take a spinlock unconditionally in the DIO fastpath · 977ec4dd
      Dave Chinner 提交于
      Because this happens at high thread counts on high IOPS devices
      doing mixed read/write AIO-DIO to a single file at about a million
      iops:
      
         64.09%     0.21%  [kernel]            [k] io_submit_one
         - 63.87% io_submit_one
            - 44.33% aio_write
               - 42.70% xfs_file_write_iter
                  - 41.32% xfs_file_dio_write_aligned
                     - 25.51% xfs_file_write_checks
                        - 21.60% _raw_spin_lock
                           - 21.59% do_raw_spin_lock
                              - 19.70% __pv_queued_spin_lock_slowpath
      
      This also happens of the IO completion IO path:
      
         22.89%     0.69%  [kernel]            [k] xfs_dio_write_end_io
         - 22.49% xfs_dio_write_end_io
            - 21.79% _raw_spin_lock
               - 20.97% do_raw_spin_lock
                  - 20.10% __pv_queued_spin_lock_slowpath
      
      IOWs, fio is burning ~14 whole CPUs on this spin lock.
      
      So, do an unlocked check against inode size first, then if we are
      at/beyond EOF, take the spinlock and recheck. This makes the
      spinlock disappear from the overwrite fastpath.
      
      I'd like to report that fixing this makes things go faster. It
      doesn't - it just exposes the the XFS_ILOCK as the next severe
      contention point doing extent mapping lookups, and that now burns
      all the 14 CPUs this spinlock was burning.
      Signed-off-by: NDave Chinner <dchinner@redhat.com>
      Reviewed-by: NCarlos Maiolino <cmaiolino@redhat.com>
      Reviewed-by: NDarrick J. Wong <djwong@kernel.org>
      Signed-off-by: NDarrick J. Wong <djwong@kernel.org>
      977ec4dd
  3. 08 4月, 2021 4 次提交
  4. 04 2月, 2021 4 次提交
  5. 02 2月, 2021 8 次提交
  6. 24 1月, 2021 2 次提交
  7. 23 1月, 2021 3 次提交
  8. 20 1月, 2021 1 次提交
  9. 22 10月, 2020 1 次提交
    • D
      xfs: fix fallocate functions when rtextsize is larger than 1 · 25219dbf
      Darrick J. Wong 提交于
      In commit fe341eb1, I forgot that xfs_free_file_space isn't strictly
      a "remove mapped blocks" function.  It is actually a function to zero
      file space by punching out the middle and writing zeroes to the
      unaligned ends of the specified range.  Therefore, putting a rtextsize
      alignment check in that function is wrong because that breaks unaligned
      ZERO_RANGE on the realtime volume.
      
      Furthermore, xfs_file_fallocate already has alignment checks for the
      functions require the file range to be aligned to the size of a
      fundamental allocation unit (which is 1 FSB on the data volume and 1 rt
      extent on the realtime volume).  Create a new helper to check fallocate
      arguments against the realtiem allocation unit size, fix the fallocate
      frontend to use it, fix free_file_space to delete the correct range, and
      remove a now redundant check from insert_file_space.
      
      NOTE: The realtime extent size is not required to be a power of two!
      
      Fixes: fe341eb1 ("xfs: ensure that fpunch, fcollapse, and finsert operations are aligned to rt extent size")
      Signed-off-by: NDarrick J. Wong <darrick.wong@oracle.com>
      Reviewed-by: NChandan Babu R <chandanrlinux@gmail.com>
      25219dbf
  10. 16 9月, 2020 1 次提交
  11. 06 9月, 2020 1 次提交
    • M
      xfs: don't update mtime on COW faults · b17164e2
      Mikulas Patocka 提交于
      When running in a dax mode, if the user maps a page with MAP_PRIVATE and
      PROT_WRITE, the xfs filesystem would incorrectly update ctime and mtime
      when the user hits a COW fault.
      
      This breaks building of the Linux kernel.  How to reproduce:
      
       1. extract the Linux kernel tree on dax-mounted xfs filesystem
       2. run make clean
       3. run make -j12
       4. run make -j12
      
      at step 4, make would incorrectly rebuild the whole kernel (although it
      was already built in step 3).
      
      The reason for the breakage is that almost all object files depend on
      objtool.  When we run objtool, it takes COW page fault on its .data
      section, and these faults will incorrectly update the timestamp of the
      objtool binary.  The updated timestamp causes make to rebuild the whole
      tree.
      Signed-off-by: NMikulas Patocka <mpatocka@redhat.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      b17164e2
  12. 06 8月, 2020 2 次提交
  13. 07 7月, 2020 5 次提交
  14. 22 6月, 2020 1 次提交
  15. 10 6月, 2020 1 次提交
  16. 20 5月, 2020 1 次提交
  17. 06 4月, 2020 2 次提交
  18. 16 1月, 2020 1 次提交