On Wed, Mar 26, 2025 at 11:54:15PM +0800, Kuan-Wei Chiu wrote: > On Wed, Mar 26, 2025 at 11:26:06AM -0400, Kent Overstreet wrote: > > Andrew - if you're ok with this patch I'd like to get it in soon as a > > bugfix, I've been getting quite a few reports on this one. > > > > I don't much care for the naming though, thoughts there? > > > > -- >8 -- > > > > bcachefs calls sort() during recovery to sort all keys it found in the > > journal, and this may be very large - gigabytes on large machines. > > > > This has been causing "task blocked" warnings, so needs a > > cond_resched(). > > > > Cc: Kuan-Wei Chiu <[email protected]> > > Cc: Andrew Morton <[email protected]> > > Signed-off-by: Kent Overstreet <[email protected]> > > --- > > include/linux/sort.h | 11 +++++++++++ > > lib/sort.c | 46 +++++++++++++++++++++++++++++++++++++++----- > > 2 files changed, 52 insertions(+), 5 deletions(-) > > > > I don't have strong opinions on this, but I recall that UBIFS had a > similar issue with list_sort(), and they addressed it by calling > cond_resched() within the compare function. Would that approach be > simpler and more appropriate than introducing a new API in the library > code?
That'd be an option, but it would be heavier; sort() has nested loops so it has a more natural place to put it. And I'd say the nonatomic scheduling version should likely be the default, anyways; even if other users aren't hitting the 10 second warning, going 1 second without scheduling isn't good. Not going to audit all the existing callers, but we should probably provide it.
