From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 C57B22C032E for ; Tue, 2 Dec 2025 18:16:21 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764699381; cv=none; b=T/y7kbiU5UoBi3h4yB+GYyrZsufF8gDutyFmfaO7Hcalyq+9+WAYBxawsLFsfce24Jkm9Dj29CUW+phL1MFNwtnjBBO/vf9sTMXcDq1itvTtdNdFXbBT5BkdM7v5SQcI225+At8x4iNVCQjwrzLdTt4Wh4AFAhmNy3ik1sFqt5c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764699381; c=relaxed/simple; bh=B79NeBUYToSmlx2gi38qTY43vEiSNGDObXBotV7h8zM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EYvGzrJ0m7tyjdWLoaNdHQDv9tu5wiD6H/D+F5CSY/TLuwfKU/DRMkx/a6j/znYFZd6I+9EljjaSdOqxLFxJQqhQomY++j6bg5SPnFkLd4atzIIrNliVyYVRu5k79ucNZ4J4PFU95GNwFNM4h9oDehFgMWYBncAH8QoxM0kk6rg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Z1LCxAjn; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Z1LCxAjn" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86C87C4CEF1; Tue, 2 Dec 2025 18:16:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1764699381; bh=B79NeBUYToSmlx2gi38qTY43vEiSNGDObXBotV7h8zM=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Z1LCxAjnyfOeFa9SfZg7ylpRWtU2ytxVS9A1nd5J4+WwVh+YDLpZCYlC4kU73hD+Z WAFEjg8syyVaEswsqx42aR4Pe+vtonEC/clDjvnTIbTeEoZ4b7/uU9f84bNise5IAn 0L24C7BbObx7q2YeNp1tLT5pgh4Y+CdZr+ydZdR3tIf253hSvSaiOECFXzyb3xKw0U HWZN2RZJDHRgAj1uJLSjzhMHP23F1LgN1hAAfkvqzh1pHr9sgM3vVhFVq1LPY2HdYw FOQtsAiD68R0pOPuRDK0SvOmHETSkIRs6XGBO9nGaWEDtejDxEsF/vTxJfZ5Rho6vZ E3urTWLwdHYUw== Date: Tue, 2 Dec 2025 08:16:20 -1000 From: Tejun Heo To: Lai Jiangshan Cc: linux-kernel@vger.kernel.org, ying chen , Lai Jiangshan Subject: Re: [PATCH V4 3/4] workqueue: Limit number of processed works in rescuer per turn Message-ID: References: <20251125063617.671199-1-jiangshanlai@gmail.com> <20251125063617.671199-4-jiangshanlai@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: <20251125063617.671199-4-jiangshanlai@gmail.com> On Tue, Nov 25, 2025 at 02:36:16PM +0800, Lai Jiangshan wrote: ... > + while (assign_rescuer_work(pwq, rescuer, ++count > RESCUER_BATCH)) > process_scheduled_works(rescuer); Can we something like the following instead? while (assign_rescuer_work(pwq, rescuer, &count)) It just feels odd to for the caller to decide "you should stop" and then taking actions on the return value of the callee. Alternatively, just separate out the pwq rotation into a separate function, so that the caller can do while (assign_rescuer_work(..)) { process_scheduled_works(rescuer); if (++count > RESCUER_BATCH) { rotate mayday list; break; } } Thanks. -- tejun