Btrfs: don't use an async starter for most of our workers
authorJosef Bacik <jbacik@fusionio.com>
Thu, 29 Aug 2013 20:51:22 +0000 (16:51 -0400)
committerChris Mason <chris.mason@fusionio.com>
Sun, 1 Sep 2013 12:16:41 +0000 (08:16 -0400)
commit45d5fd14d22304c9a40d5aae75ec610f5d1cbb53
treec2c69e5e856b5da2ed9d8b3920d0988f84e44e89
parent7f4f6e0a3f6db9c214de38c792c483b8076bcd6a
Btrfs: don't use an async starter for most of our workers

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>
fs/btrfs/disk-io.c