Skip to content

Commit

Permalink
Btrfs: don't use an async starter for most of our workers
Browse files Browse the repository at this point in the history
We only need an async starter if we can't make a GFP_NOFS allocation in our
current path.  This is the case for the endio stuff since it happens in IRQ
context, but things like the caching thread workers and the delalloc flushers we
can easily make this allocation and start threads right away.  Also change the
worker count for the caching thread pool.  Traditionally we limited this to 2
since we took read locks while caching, but nowadays we do this lockless so
there's no reason to limit the number of caching threads.  Thanks,

Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
  • Loading branch information
Josef Bacik authored and Chris Mason committed Sep 1, 2013
1 parent 7f4f6e0 commit 45d5fd1
Showing 1 changed file with 4 additions and 7 deletions.
11 changes: 4 additions & 7 deletions fs/btrfs/disk-io.c
Original file line number Diff line number Diff line change
Expand Up @@ -2483,20 +2483,17 @@ int open_ctree(struct super_block *sb,
&fs_info->generic_worker);

btrfs_init_workers(&fs_info->delalloc_workers, "delalloc",
fs_info->thread_pool_size,
&fs_info->generic_worker);
fs_info->thread_pool_size, NULL);

btrfs_init_workers(&fs_info->flush_workers, "flush_delalloc",
fs_info->thread_pool_size,
&fs_info->generic_worker);
fs_info->thread_pool_size, NULL);

btrfs_init_workers(&fs_info->submit_workers, "submit",
min_t(u64, fs_devices->num_devices,
fs_info->thread_pool_size),
&fs_info->generic_worker);
fs_info->thread_pool_size), NULL);

btrfs_init_workers(&fs_info->caching_workers, "cache",
2, &fs_info->generic_worker);
fs_info->thread_pool_size, NULL);

/* a higher idle thresh on the submit workers makes it much more
* likely that bios will be send down in a sane order to the
Expand Down

0 comments on commit 45d5fd1

Please sign in to comment.