| Message ID | 26ea5e38363115b0a35bf7e56078a552075c9ca7.1655159467.git.josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: reset block group chunk force if we have to wait | expand |
On Mon, Jun 13, 2022 at 06:31:17PM -0400, Josef Bacik wrote: > If you try to force a chunk allocation, but you race with another chunk > allocation, you will end up waiting on the chunk allocation that just > occurred and then allocate another chunk. If you have many threads all > doing this at once you can way over-allocate chunks. > > Fix this by resetting force to NO_FORCE, that way if we think we need to > allocate we can, otherwise we don't force another chunk allocation if > one is already happening. > > Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Filipe Manana <fdmanana@suse.com> Looks good, thanks. > --- > fs/btrfs/block-group.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c > index ede389f2602d..13358fbc1629 100644 > --- a/fs/btrfs/block-group.c > +++ b/fs/btrfs/block-group.c > @@ -3761,6 +3761,7 @@ int btrfs_chunk_alloc(struct btrfs_trans_handle *trans, u64 flags, > * attempt. > */ > wait_for_alloc = true; > + force = CHUNK_ALLOC_NO_FORCE; > spin_unlock(&space_info->lock); > mutex_lock(&fs_info->chunk_mutex); > mutex_unlock(&fs_info->chunk_mutex); > -- > 2.26.3 >
On Mon, Jun 13, 2022 at 06:31:17PM -0400, Josef Bacik wrote:
> If you try to force a chunk allocation,
Do you mean using the new sysfs force_chunk_allocation ? As the patch
stands I think it could be applied independently but not later than the
sysfs chunk series, or folded in but I'm not sure it's a good idea.
On Mon, Jun 13, 2022 at 06:31:17PM -0400, Josef Bacik wrote: > If you try to force a chunk allocation, but you race with another chunk > allocation, you will end up waiting on the chunk allocation that just > occurred and then allocate another chunk. If you have many threads all > doing this at once you can way over-allocate chunks. > > Fix this by resetting force to NO_FORCE, that way if we think we need to > allocate we can, otherwise we don't force another chunk allocation if > one is already happening. > > Signed-off-by: Josef Bacik <josef@toxicpanda.com> Added to misc-next, thanks.
diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index ede389f2602d..13358fbc1629 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -3761,6 +3761,7 @@ int btrfs_chunk_alloc(struct btrfs_trans_handle *trans, u64 flags, * attempt. */ wait_for_alloc = true; + force = CHUNK_ALLOC_NO_FORCE; spin_unlock(&space_info->lock); mutex_lock(&fs_info->chunk_mutex); mutex_unlock(&fs_info->chunk_mutex);
If you try to force a chunk allocation, but you race with another chunk allocation, you will end up waiting on the chunk allocation that just occurred and then allocate another chunk. If you have many threads all doing this at once you can way over-allocate chunks. Fix this by resetting force to NO_FORCE, that way if we think we need to allocate we can, otherwise we don't force another chunk allocation if one is already happening. Signed-off-by: Josef Bacik <josef@toxicpanda.com> --- fs/btrfs/block-group.c | 1 + 1 file changed, 1 insertion(+)