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 7F8C4233707 for ; Fri, 21 Nov 2025 19:28:58 +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=1763753339; cv=none; b=CTlfRQhe91YSQugZhGCPDHK6J9YCDoKBlZLQqrghjTStTFBHRcywatIjgJMfexRGMDzNOFmFJb17Ge4JyX8ckQUZeVVclnFIpYommGqmxHZBiqLIZ273ns3MV2QhjnqeoGGWWkxZlGP14GInK6e1skvqLsAyvBeKmgAOUQwLxZI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763753339; c=relaxed/simple; bh=V/tSUSmrTNg33Q+XW88TtyZ6wkbSmekdib5mtC+TPrI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=bXgCz3FEwqp5TsOhl+ZeqgPCGnqUga94ZaPiQ5ko6pfz4fZiZKI0lg8M5Jbq+eidx85fMJhAZoMe2nZN8HFwytOO5gPedIFNkAx6cr6mnX7eAH3mqS9N62vcjvo33XwZLCUWtpQAz6sZtZgpmX2QKx8RG7Nayx7DcKOGODfOYCY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=cunSlokP; 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="cunSlokP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E84E4C4CEF1; Fri, 21 Nov 2025 19:28:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763753338; bh=V/tSUSmrTNg33Q+XW88TtyZ6wkbSmekdib5mtC+TPrI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=cunSlokPygexcWzdbqMd6PX8i//zPkVV6TubxjZ+DN0pjcbIgukFVQs/3apROH8+A y4DnQHLAayZrY2sgGFPZuiZgXMIZTnOrDTYidnFBhEBNL0CKJlEwq4+hsTQi0bZE0X Y/6qj+sx+Qg3+FCaY/DEUKU3CbMzwZYe8Bkd2Eav+B3Ml1b57TQhunko26O5k1jaYv +nETmONQQjdXRYiSIhXoU5b8rDb2m3AyVVaBH6gD8biUEf9bVk5SIUH/E4BIsVBH8m 9PJjYtlfyTRFXKYtG5blNqEm1boUdojf2p46raSFXgNSchaAPyfAZdIdm4ZhueLrJg Ae5x+bD/MySTw== Date: Fri, 21 Nov 2025 09:28:56 -1000 From: Tejun Heo To: Lai Jiangshan Cc: linux-kernel@vger.kernel.org, ying chen , Lai Jiangshan Subject: Re: [PATCH V3 6/7] workqueue: Limit number of processed works in rescuer per turn Message-ID: References: <20251121145720.342467-1-jiangshanlai@gmail.com> <20251121145720.342467-7-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: <20251121145720.342467-7-jiangshanlai@gmail.com> Hello, On Fri, Nov 21, 2025 at 10:57:19PM +0800, Lai Jiangshan wrote: > +static bool assign_rescuer_work(struct pool_workqueue *pwq, struct worker *rescuer, bool limited) I find the organization a bit odd with the expiration detection in the caller and the implmentation of it piped into this function. Please see below. > list_for_each_entry_safe_from(work, n, &pool->worklist, entry) { > - if (get_work_pwq(work) == pwq && assign_work(work, rescuer, &n)) { > + if (get_work_pwq(work) != pwq) > + continue; > + /* > + * put the cursor, resend mayday for itself and move on to other > + * PWQs when the limit is reached. > + */ > + if (limited && !list_empty(&pwq->wq->maydays)) { > + list_add_tail(&cursor->entry, &work->entry); > + raw_spin_lock(&wq_mayday_lock); /* for wq->maydays */ > + send_mayday(work); > + raw_spin_unlock(&wq_mayday_lock); > + return false; Does it make sense to maintain cursor position across pwqs? Shouldn't it be reset? Imagine two pwqs' (A, B) work items interleaved: A1 B1 A2 B2 A3 B3 1. Two of A's work items are rescued and cursor is inserted before the next eligible one: B1 B2 A3 B3 ^ 2. Let's say limit is reached and we're moving on to B. Then, the rescuer would first run B3. Wouldn't it make more sense to go back to the head of the queue and start over so that it can pick up B1 first? Thanks. -- tejun