From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (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 1D0B535DA52 for ; Wed, 18 Mar 2026 05:57:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.137.202.133 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773813447; cv=none; b=P+q+6ITBp/8roYGvtGvIaU3Z6eh236AzBakPXu1LzhFpy1DHWa2WuTpZ9Xx+8KhQrmXRy1NuURASZC0YIxXer/c0Tt5SaWHAljjvFGsPT+WOg/WnYudaDmQl1VgFiDJvV8GweexfJkH5SNxk2o6/VKbDd+Pr4odRQSS+HEtANWk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773813447; c=relaxed/simple; bh=TLfrytG5aPpVAgmVZ6X6I7KelaX4RLWMXgbGy47H46s=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=iDh+HLQc0u0gi3l0Q53/5teBjy2XkDN1SIYs5xVW2NBzAXZz2Rgc8Jgbdnn1V+20dgYdSAuaQxNfYz/8k3y6hqKQJeGPlkU9NiHlYpXsbobxtt7pnJGNQfM2O3RlrHam9QtchSRw5yVQcS8yShBkiTJSiOdXP3/E13JghOXayPY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=gYgjcvnN; arc=none smtp.client-ip=198.137.202.133 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=bombadil.srs.infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="gYgjcvnN" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=1wRyL6lVS10oRefBQ1vo+uMTYQqWVeA1Yi9d0ml3u9I=; b=gYgjcvnNQcevrTv/LyThWDlXTm z9YiIuJTKey2mVhcBTwj+LHTDSWkBm2ig1YA1Bi300a6LV1rPBEBfLSlme4B0Tt6ptZyudBJnzApq Tzm3UonE80GAlb+3CS4isIFx4q/GOzsB8wo0SIrk+5+swMVURh306uTbUkbN+Z93ZRKCNBnlRrtTc ABcz5CS7ULWMynX/PluccN+uvhwkkYAqcX/Yu2e6eZn04UIEHgFrjQDdAW7O/Ni6TSCl4yYHICGEf 35z8xUT6ulLEbdXuKKWzShBGDRl5NQQlzp+q09NOtZaL3tB9lJNnTPRHSj07+xbCPBc4hU8dYUxZT Iv2Ci7RA==; Received: from hch by bombadil.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1w2juA-00000007os6-2QuQ; Wed, 18 Mar 2026 05:57:18 +0000 Date: Tue, 17 Mar 2026 22:57:18 -0700 From: Christoph Hellwig To: Kuan-Wei Chiu Cc: richard@nod.at, akpm@linux-foundation.org, 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 v2] lib/list_sort: introduce list_sort_nonatomic() and clean up scheduling workarounds Message-ID: References: <20260317165905.1482256-1-visitorckw@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260317165905.1482256-1-visitorckw@gmail.com> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html On Tue, Mar 17, 2026 at 04:59:05PM +0000, Kuan-Wei Chiu wrote: > Historically, list_sort() implemented a hack in merge_final(): > if (unlikely(!++count)) > cmp(priv, b, b); > > This was designed specifically so that callers could periodically > invoke cond_resched() within their comparison functions when merging > highly unbalanced lists. > > However, an audit of the kernel tree reveals that only fs/ubifs/ relies > on this mechanism. For the vast majority of list_sort() users (such as > block layer IO schedulers and file systems), this results in completely > wasted function calls. In the worst-case scenario (merging an already > sorted list where 'a' is exhausted quickly), it results in > approximately (N/2)/256 unnecessary cmp() calls. > > To clean up this API, eliminate the overhead for generic users, and > consolidate the scheduling logic: > 1. Introduce list_sort_nonatomic(), which explicitly calls > cond_resched() within its inner merge loops. > 2. Remove the dummy cmp(priv, b, b) fallback from standard list_sort(), > saving unnecessary function calls and improving determinism for all > other subsystems. > 3. Convert the sole user (fs/ubifs/) to the new API and completely > remove cond_resched() from UBIFS's comparison callbacks, unpolluting > its comparison logic. > > 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. 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.