Messages in this thread | | | From | Mark Brown <> | Subject | Re: [PATCH] regcache: Push async I/O request down into the rbtree cache | Date | Fri, 21 Jul 2023 18:41:15 +0100 |
| |
On Wed, 19 Jul 2023 00:30:40 +0100, Mark Brown wrote: > Currently the regcache core unconditionally enables async I/O for all cache > types, causing problems for the maple tree cache which dynamically allocates > the buffers used to write registers to the device since async requires the > buffers to be kept around until the I/O has been completed. > > This use of async I/O is mainly for the rbtree cache which stores data in > a format directly usable for regmap_raw_write(), though there is a special > case for single register writes which would also have allowed it to be used > with the flat cache. It is a bit of a landmine for other caches since it > implicitly converts sync operations to async, and with modern hardware it > is not clear that async I/O is actually a performance win as shown by the > performance work David Jander did with SPI. In multi core systems the cost > of managing concurrency ends up swamping the performance benefit and almost > all modern systems are multi core. > > [...]
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git for-next
Thanks!
[1/1] regcache: Push async I/O request down into the rbtree cache commit: b460a52257b1f5299ca70b7d1bb32442d3ce7bf6
All being well this means that it will be integrated into the linux-next tree (usually sometime in the next 24 hours) and sent to Linus during the next merge window (or sooner if it is a bug fix), however if problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing and review of the tree, please engage with people reporting problems and send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they should be sent as incremental updates against current git, existing patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying to this mail.
Thanks, Mark
| |