From: Andrew Morton <akpm@linux-foundation.org>
To: Kuan-Wei Chiu <visitorckw@gmail.com>
Cc: richard@nod.at, chengzhihao1@huawei.com, hch@infradead.org,
jserv@ccns.ncku.edu.tw, eleanor15x@gmail.com,
marscheng@google.com, linux-mtd@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v3 0/2] lib/list_sort: Clean up list_sort() scheduling workarounds
Date: Fri, 20 Mar 2026 18:21:04 -0700 [thread overview]
Message-ID: <20260320182104.fc8ec409731591d7021c6777@linux-foundation.org> (raw)
In-Reply-To: <20260320180938.1827148-1-visitorckw@gmail.com>
On Fri, 20 Mar 2026 18:09:36 +0000 Kuan-Wei Chiu <visitorckw@gmail.com> wrote:
> Historically, list_sort() included a hack in merge_final() that
> periodically invoked dummy cmp(priv, b, b) calls when merging highly
> unbalanced lists. This allowed the caller to invoke cond_resched()
> within their comparison callbacks to avoid soft lockups.
>
> However, an audit of the kernel tree shows that fs/ubifs/ has been the
> sole user of this mechanism. For all other generic list_sort() users,
> this results in wasted function calls and unnecessary overhead in a
> tight loop.
>
> Recent discussions and code inspection confirmed that the lists being
> sorted in UBIFS are bounded in size (a few thousand elements at most),
> and the comparison functions are extremely lightweight. Therefore,
> UBIFS does not actually need to rely on this mechanism.
Thanks. AI review found a now-unused local, which I'll fix.
https://sashiko.dev/#/patchset/20260320180938.1827148-1-visitorckw@gmail.com
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
prev parent reply other threads:[~2026-03-21 1:21 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-20 18:09 [PATCH v3 0/2] lib/list_sort: Clean up list_sort() scheduling workarounds Kuan-Wei Chiu
2026-03-20 18:09 ` [PATCH v3 1/2] ubifs: Remove unnecessary cond_resched() from list_sort() compare Kuan-Wei Chiu
2026-03-21 2:06 ` Zhihao Cheng
2026-03-25 7:18 ` Richard Weinberger
2026-03-20 18:09 ` [PATCH v3 2/2] lib/list_sort: Remove dummy cmp() calls to speed up merge_final() Kuan-Wei Chiu
2026-03-25 5:44 ` Christoph Hellwig
2026-03-21 1:21 ` Andrew Morton [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=20260320182104.fc8ec409731591d7021c6777@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=chengzhihao1@huawei.com \
--cc=eleanor15x@gmail.com \
--cc=hch@infradead.org \
--cc=jserv@ccns.ncku.edu.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=marscheng@google.com \
--cc=richard@nod.at \
--cc=visitorckw@gmail.com \
/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.