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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox