On Mon, May 17, 2021 at 07:07:04AM +0000, Johannes Thumshirn wrote:

On 12/05/2021 16:44, David Sterba wrote:

quoted

On Wed, May 12, 2021 at 11:01:40PM +0900, Johannes Thumshirn wrote:

quoted

+	if (use_append) {
+		struct extent_map *em;
+		struct map_lookup *map;
+
+		em = btrfs_get_chunk_map(fs_info, disk_start, PAGE_SIZE);

The caller already does the em lookup, so this is duplicate, allocating
memory, taking locks and doing a tree lookup. All happening on write out
path so this seems heavy.

Right, I did not check this, sorry. Is it OK to add another patch as 
preparation swapping some of the parameters to btrfs_submit_compressed_write()
from the em?

That would be another prep patch for the fix, I can't say now if this
would be still suitable for stable.

Otherwise btrfs_submit_compressed_write() will have 10 parameters
which sounds awefull.

In case the fix would have to be in one patch, extending the parameters
to 10 would be acceptable, if followed by reduction cleanup (that won't
have to be backported).

If you check the only caller of btrfs_submit_compressed_write, four
parameters are from async_extent, and two are async_chunk, where
async_extent = list_entry(async_chunk->extents.next, ...) so that should
be easy to reduce.