From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lithops.sigma-star.at (mailout.nod.at [116.203.167.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 86A053B776A for ; Wed, 18 Mar 2026 10:08:00 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=116.203.167.152 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773828487; cv=none; b=B/Ge2wElug27Acrs5xl3hG05N9Y/kOrN9e0WfQApnGldcUYYmcik+DS6F/rmp2sJOM2T3mgxD26sJ8pX1KSIjkI8FBgvB8bpMQgg677I9LWtbcFxHmeoH0ULqshmfq4Btp9dlq5tl23W4tZHzqFEkCkMinYLvMElDPXjEy3JVXY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773828487; c=relaxed/simple; bh=SVBA/e9rvdogTpUN2sG45O2X/JJRuWqc7PBg/T+s32o=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: MIME-Version:Content-Type; b=CyXLs7XcU4PnwU8DFwJCK5udKo/x/tv31JB+VEzS8ix3SFzWjBydJ+nZBhzLsflHXBTr0qwUu9yOKaSgNpGvagZN4E2xm3T9rWF1C/kbquDE/7rOoFY/kPLRVklmaOe/dtvaTQG+bJjD+XTJ6mLyLI5+COdBzUaZM0v6Y4/AURc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at; spf=fail smtp.mailfrom=nod.at; arc=none smtp.client-ip=116.203.167.152 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=nod.at Authentication-Results: smtp.subspace.kernel.org; spf=fail smtp.mailfrom=nod.at Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id CD785BE348; Wed, 18 Mar 2026 11:07:52 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id SMu1kEsC8XZk; Wed, 18 Mar 2026 11:07:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by lithops.sigma-star.at (Postfix) with ESMTP id D5D0DBE34D; Wed, 18 Mar 2026 11:07:51 +0100 (CET) Received: from lithops.sigma-star.at ([127.0.0.1]) by localhost (lithops.sigma-star.at [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Gs6UkXmNPkGl; Wed, 18 Mar 2026 11:07:51 +0100 (CET) Received: from lithops.sigma-star.at (lithops.sigma-star.at [195.201.40.130]) by lithops.sigma-star.at (Postfix) with ESMTP id A945FBE346; Wed, 18 Mar 2026 11:07:51 +0100 (CET) Date: Wed, 18 Mar 2026 11:07:51 +0100 (CET) From: Richard Weinberger To: Christoph Hellwig Cc: Kuan-Wei Chiu , Andrew Morton , chengzhihao1 , jserv , eleanor15x , marscheng , linux-mtd , linux-kernel Message-ID: <566555015.53186.1773828471518.JavaMail.zimbra@nod.at> In-Reply-To: References: <20260317165905.1482256-1-visitorckw@gmail.com> Subject: Re: [PATCH v2] lib/list_sort: introduce list_sort_nonatomic() and clean up scheduling workarounds Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Zimbra 8.8.12_GA_3807 (ZimbraWebClient - FF148 (Linux)/8.8.12_GA_3809) Thread-Topic: lib/list_sort: introduce list_sort_nonatomic() and clean up scheduling workarounds Thread-Index: yTkjJ6vHpIDh1IwbTwoEKqnlDnYBOg== ----- Urspr=C3=BCngliche Mail ----- > Von: "Christoph Hellwig" >> This change leaves the generic list_sort() completely free of >> scheduling hacks, simplifies UBIFS's callbacks, and ensures that legacy >> long-list sorting workloads remain safe from soft lockups on >> non-preemptible kernels. >=20 > As said before we really should not add the extra nonatomic API > and just do the right thing, and drop the cond_resched in ubifs > in a prep patch. I think you are right. After inspecting UBIFS's usage of list_sort() I feel more confident that we can remove the calls to cond_resched() from the compare functions. The compare functions are rather cheap, they don't do (blocking) MTD io. In the GC case each list contains at most as many UBIFS nodes you can stuff into a single LEB. The replay case is a little different, the replay list can contain elements from multiple LEBs. But the UBIFS journal is limited to a few LEBs, so the list is likely always at most a few thousand elements long. So, we always talk about calling the compare functions a few thousand times, not millions times. Thanks, //richard