On Mon, Apr 10, 2017 at 04:00:25PM +0200, David Sterba wrote: > On Mon, Apr 10, 2017 at 09:25:18AM +0800, Qu Wenruo wrote: > > > > > > At 04/07/2017 08:00 PM, David Sterba wrote: > > > On Mon, Mar 13, 2017 at 03:52:15PM +0800, Qu Wenruo wrote: > > >> @@ -3355,12 +3355,14 @@ static int cache_save_setup(struct > > >> btrfs_block_group_cache *block_group, > > >> struct btrfs_fs_info *fs_info = block_group->fs_info; > > >> struct btrfs_root *root = fs_info->tree_root; > > >> struct inode *inode = NULL; > > >> + struct extent_changeset data_reserved; > > > > > > Size of this structure is 40 bytes, and it's being added to many > > > functions. This will be noticeable on the stack consumption. > > > > > > -extent-tree.c:btrfs_check_data_free_space 40 static > > > -extent-tree.c:cache_save_setup 96 static > > > +extent-tree.c:btrfs_check_data_free_space 48 static > > > +extent-tree.c:cache_save_setup 136 static > > > -file.c:__btrfs_buffered_write 192 static > > > +file.c:__btrfs_buffered_write 232 static > > > -file.c:btrfs_fallocate 208 static > > > +file.c:btrfs_fallocate 248 static > > > -inode-map.c:btrfs_save_ino_cache 112 static > > > +inode-map.c:btrfs_save_ino_cache 152 static > > > -inode.c:btrfs_direct_IO 128 static > > > +inode.c:btrfs_direct_IO 176 static > > > -inode.c:btrfs_writepage_fixup_worker 88 static > > > +inode.c:btrfs_writepage_fixup_worker 128 static > > > -inode.c:btrfs_truncate_block 136 static > > > +inode.c:btrfs_truncate_block 176 static > > > -inode.c:btrfs_page_mkwrite 112 static > > > +inode.c:btrfs_page_mkwrite 152 static > > > +ioctl.c:cluster_pages_for_defrag 200 static > > > -ioctl.c:btrfs_defrag_file 312 static > > > +ioctl.c:btrfs_defrag_file 232 static > > > -qgroup.c:btrfs_qgroup_reserve_data 136 static > > > +qgroup.c:btrfs_qgroup_reserve_data 128 static > > > -relocation.c:prealloc_file_extent_cluster 152 static > > > +relocation.c:prealloc_file_extent_cluster 192 static > > > > > > There are generic functions so this will affect non-qgroup workloads as > > > well. So there need to be a dynamic allocation (which would add another > > > point of failure), or reworked in another way. > > > > Well, I'll try to rework this to allocate extent_changeset inside > > btrfs_qgroup_reserve_data(), so that callers only need extra 8 bytes > > stack space, and no need to introduce extra error handlers. > > So this still requires the dynamic allocation, on various call paths, > that's what I object against most at the moment.
I get that we cannot easily avoid using the extent_changeset, so we'll end up one way or another, the stack conservation has slight preference. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
