From: Kuan-Wei Chiu <visitorckw@gmail.com>
To: richard@nod.at, akpm@linux-foundation.org
Cc: 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,
Kuan-Wei Chiu <visitorckw@gmail.com>
Subject: [PATCH v3 1/2] ubifs: Remove unnecessary cond_resched() from list_sort() compare
Date: Fri, 20 Mar 2026 18:09:37 +0000 [thread overview]
Message-ID: <20260320180938.1827148-2-visitorckw@gmail.com> (raw)
In-Reply-To: <20260320180938.1827148-1-visitorckw@gmail.com>
Historically, UBIFS embedded cond_resched() calls inside its
list_sort() comparison callbacks (data_nodes_cmp, nondata_nodes_cmp,
and replay_entries_cmp) to prevent soft lockups when sorting long
lists.
However, further inspection by Richard Weinberger reveals that these
compare functions are extremely lightweight and do not perform any
blocking MTD I/O. Furthermore, the lists being sorted are strictly
bounded in size:
- In the GC case, the list contains at most the number of nodes that
fit into a single LEB.
- In the replay case, the list spans across a few LEBs from the UBIFS
journal, amounting to at most a few thousand elements.
Since the compare functions are called a few thousand times at most,
the overhead of frequent scheduling points is unjustified. Removing the
cond_resched() calls simplifies the comparison logic and reduces
unnecessary context switch checks during the sort.
Signed-off-by: Kuan-Wei Chiu <visitorckw@gmail.com>
---
fs/ubifs/gc.c | 2 --
fs/ubifs/replay.c | 1 -
2 files changed, 3 deletions(-)
diff --git a/fs/ubifs/gc.c b/fs/ubifs/gc.c
index 0bf08b7755b8..933c79b5cd6b 100644
--- a/fs/ubifs/gc.c
+++ b/fs/ubifs/gc.c
@@ -109,7 +109,6 @@ static int data_nodes_cmp(void *priv, const struct list_head *a,
struct ubifs_info *c = priv;
struct ubifs_scan_node *sa, *sb;
- cond_resched();
if (a == b)
return 0;
@@ -153,7 +152,6 @@ static int nondata_nodes_cmp(void *priv, const struct list_head *a,
struct ubifs_info *c = priv;
struct ubifs_scan_node *sa, *sb;
- cond_resched();
if (a == b)
return 0;
diff --git a/fs/ubifs/replay.c b/fs/ubifs/replay.c
index a9a568f4a868..263045e05cf1 100644
--- a/fs/ubifs/replay.c
+++ b/fs/ubifs/replay.c
@@ -305,7 +305,6 @@ static int replay_entries_cmp(void *priv, const struct list_head *a,
struct ubifs_info *c = priv;
struct replay_entry *ra, *rb;
- cond_resched();
if (a == b)
return 0;
--
2.53.0.959.g497ff81fa9-goog
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
next prev parent reply other threads:[~2026-03-20 18:10 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 ` Kuan-Wei Chiu [this message]
2026-03-21 2:06 ` [PATCH v3 1/2] ubifs: Remove unnecessary cond_resched() from list_sort() compare 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 ` [PATCH v3 0/2] lib/list_sort: Clean up list_sort() scheduling workarounds Andrew Morton
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=20260320180938.1827148-2-visitorckw@gmail.com \
--to=visitorckw@gmail.com \
--cc=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 \
/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.