summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/parallel-perf.py
diff options
context:
space:
mode:
authorBrian Foster <bfoster@redhat.com>2025-12-08 09:05:48 -0500
committerChristian Brauner <brauner@kernel.org>2025-12-15 15:17:44 +0100
commited61378b4dc63efe76cb8c23a36b228043332da3 (patch)
tree548d6796542c232cf3d45438ee79e092c627df0e /tools/perf/scripts/python/parallel-perf.py
parenta260bd22a355bcdb74cedac6ab9b10739cd2c62c (diff)
downloadkernel-ed61378b4dc63efe76cb8c23a36b228043332da3.tar.gz
iomap: replace folio_batch allocation with stack allocation
Zhang Yi points out that the dynamic folio_batch allocation in iomap_fill_dirty_folios() is problematic for the ext4 on iomap work that is under development because it doesn't sufficiently handle the allocation failure case (by allowing a retry, for example). We've also seen lockdep (via syzbot) complain recently about the scope of the allocation. The dynamic allocation was initially added for simplicity and to help indicate whether the batch was used or not by the calling fs. To address these issues, put the batch on the stack of iomap_zero_range() and use a flag to control whether the batch should be used in the iomap folio lookup path. This keeps things simple and eliminates allocation issues with lockdep and for ext4 on iomap. While here, also clean up the fill helper signature to be more consistent with the underlying filemap helper. Pass through the return value of the filemap helper (folio count) and update the lookup offset via an out param. Fixes: 395ed1ef0012 ("iomap: optional zero range dirty folio processing") Signed-off-by: Brian Foster <bfoster@redhat.com> Link: https://patch.msgid.link/20251208140548.373411-1-bfoster@redhat.com Acked-by: Dave Chinner <dchinner@redhat.com> Reviewed-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Darrick J. Wong <djwong@kernel.org> Signed-off-by: Christian Brauner <brauner@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/parallel-perf.py')
0 files changed, 0 insertions, 0 deletions
DMA controller has to exposed its number of request line to be addressed via STM32 DMAMUX. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Signed-off-by: Pierre-Yves MORDRET <pierre-yves.mordret@st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com> 2017-01-03dt-bindings: stm32-dma: Fix typo regarding DMA client bindingM'boumba Cedric Madianga Only four cells are required for dma client binding not five. Signed-off-by: M'boumba Cedric Madianga <cedric.madianga@gmail.com> Reviewed-by: Ludovic BARRE <ludovic.barre@st.com> Acked-by: Rob Herring <robh@kernel.org> Signed-off-by: Vinod Koul <vinod.koul@intel.com>