From: Brian Foster <bfoster@redhat.com>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: linux-bcachefs@vger.kernel.org
Subject: Re: [PATCH] bcachefs: update alloc cursor in early bucket allocator
Date: Fri, 20 Oct 2023 12:01:06 -0400 [thread overview]
Message-ID: <ZTKkQhiF4aD5ZYpw@bfoster> (raw)
In-Reply-To: <20231019183803.njsjs4sz7p4zpyfc@moria.home.lan>
On Thu, Oct 19, 2023 at 02:38:03PM -0400, Kent Overstreet wrote:
> On Thu, Oct 19, 2023 at 01:22:38PM -0400, Brian Foster wrote:
> > BTW, should this code be protected from no free space situations at a
> > higher level, or should we consider a max retry count or something? I
> > want to be cautious about things like prospective livelocks
> > (particularly if this path is less common) if this retry was effectively
> > dead code due to not updating alloc_cursor.
>
> It should be limiting itself to a single retry already: on retry, we set
> alloc_cursor = alloc_start, so we won't retry again. Just make sure that
> still works :)
>
I don't think that actually works due to the whole alloc_cursor not
updating thing, but regardless the "single retry from the beginning"
logic makes a lot more sense to me. With that, here's what I'm currently
playing with:
diff --git a/fs/bcachefs/alloc_foreground.c b/fs/bcachefs/alloc_foreground.c
index 3bc4abd3d7d5..41a7bf24c440 100644
--- a/fs/bcachefs/alloc_foreground.c
+++ b/fs/bcachefs/alloc_foreground.c
@@ -402,8 +402,9 @@ bch2_bucket_alloc_early(struct btree_trans *trans,
struct btree_iter iter;
struct bkey_s_c k;
struct open_bucket *ob = NULL;
- u64 alloc_start = max_t(u64, ca->mi.first_bucket, ca->new_fs_bucket_idx);
- u64 alloc_cursor = max(alloc_start, READ_ONCE(ca->alloc_cursor));
+ u64 first_bucket = max_t(u64, ca->mi.first_bucket, ca->new_fs_bucket_idx);
+ u64 alloc_start = max(first_bucket, READ_ONCE(ca->alloc_cursor));
+ u64 alloc_cursor = alloc_start;
int ret;
again:
for_each_btree_key_norestart(trans, iter, BTREE_ID_alloc, POS(ca->dev_idx, alloc_cursor),
@@ -431,13 +432,14 @@ bch2_bucket_alloc_early(struct btree_trans *trans,
}
bch2_trans_iter_exit(trans, &iter);
+ alloc_cursor = iter.pos.offset;
ca->alloc_cursor = alloc_cursor;
if (!ob && ret)
ob = ERR_PTR(ret);
- if (!ob && alloc_cursor > alloc_start) {
- alloc_cursor = alloc_start;
+ if (!ob && alloc_start > first_bucket) {
+ alloc_cursor = alloc_start = first_bucket;
goto again;
}
prev parent reply other threads:[~2023-10-20 16:01 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-19 13:27 [PATCH] bcachefs: update alloc cursor in early bucket allocator Brian Foster
2023-10-19 15:30 ` Kent Overstreet
2023-10-19 17:22 ` Brian Foster
2023-10-19 18:38 ` Kent Overstreet
2023-10-20 16:01 ` Brian Foster [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZTKkQhiF4aD5ZYpw@bfoster \
--to=bfoster@redhat.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-bcachefs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.