bcachefs: Bump limit in btree_trans_too_many_iters()
Signed-off-by: Kent Overstreet <kent.overstreet@linux.dev>
This commit is contained in:
parent
01e5f4fc0f
commit
be42e4a621
|
@ -642,7 +642,7 @@ int __bch2_btree_trans_too_many_iters(struct btree_trans *);
|
|||
|
||||
static inline int btree_trans_too_many_iters(struct btree_trans *trans)
|
||||
{
|
||||
if (bitmap_weight(trans->paths_allocated, trans->nr_paths) > BTREE_ITER_INITIAL - 8)
|
||||
if (bitmap_weight(trans->paths_allocated, trans->nr_paths) > BTREE_ITER_NORMAL_LIMIT - 8)
|
||||
return __bch2_btree_trans_too_many_iters(trans);
|
||||
|
||||
return 0;
|
||||
|
|
|
@ -364,7 +364,21 @@ struct btree_insert_entry {
|
|||
unsigned long ip_allocated;
|
||||
};
|
||||
|
||||
/* Number of btree paths we preallocate, usually enough */
|
||||
#define BTREE_ITER_INITIAL 64
|
||||
/*
|
||||
* Lmiit for btree_trans_too_many_iters(); this is enough that almost all code
|
||||
* paths should run inside this limit, and if they don't it usually indicates a
|
||||
* bug (leaking/duplicated btree paths).
|
||||
*
|
||||
* exception: some fsck paths
|
||||
*
|
||||
* bugs with excessive path usage seem to have possibly been eliminated now, so
|
||||
* we might consider eliminating this (and btree_trans_too_many_iter()) at some
|
||||
* point.
|
||||
*/
|
||||
#define BTREE_ITER_NORMAL_LIMIT 256
|
||||
/* never exceed limit */
|
||||
#define BTREE_ITER_MAX (1U << 10)
|
||||
|
||||
struct btree_trans_commit_hook;
|
||||
|
|
Loading…
Reference in New Issue