[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <xhsmhcz97l3tx.mognet@vschneid.remote.csb>
Date: Mon, 28 Nov 2022 11:24:10 +0000
From: Valentin Schneider <vschneid@...hat.com>
To: Tejun Heo <tj@...nel.org>
Cc: linux-kernel@...r.kernel.org,
Lai Jiangshan <jiangshanlai@...il.com>,
Peter Zijlstra <peterz@...radead.org>,
Frederic Weisbecker <frederic@...nel.org>,
Juri Lelli <juri.lelli@...hat.com>,
Phil Auld <pauld@...hat.com>,
Marcelo Tosatti <mtosatti@...hat.com>
Subject: Re: [PATCH v5 4/5] workqueue: Convert the idle_timer to a timer +
work_struct
On 22/11/22 10:23, Tejun Heo wrote:
> Hello,
>
Thanks for having a look at this so quickly!
> On Tue, Nov 22, 2022 at 07:29:36PM +0000, Valentin Schneider wrote:
>> @@ -2039,12 +2060,48 @@ static void idle_worker_timeout(struct timer_list *t)
>> worker = list_entry(pool->idle_list.prev, struct worker, entry);
>> expires = worker->last_active + IDLE_WORKER_TIMEOUT;
>>
>> + /* All remaining entries will be younger than this */
>> if (time_before(jiffies, expires)) {
>> - mod_timer(&pool->idle_timer, expires);
>> + if (!cull_cnt)
>> + mod_timer(&pool->idle_timer, expires);
>> break;
>> }
>>
>> + /*
>> + * Mark the idle worker ripe for culling.
>> + * If a preempted idle worker gets to run before the idle cull
>> + * handles it, it will just pop itself out of that list and
>> + * continue as normal.
>> + */
>> + list_move(&worker->entry, &pool->idle_cull_list);
>> + }
>> + raw_spin_unlock_irq(&pool->lock);
>> +
>> + if (cull_cnt)
>> + queue_work(system_unbound_wq, &pool->idle_cull_work);
>> +}
>
> So, you mentioned this explicitly in the cover letter but I think I'd prefer
> if the timer were simpler and all logic were in the work item. It just needs
> to pick at the first worker and compare the expiration once, right?
Yep exactly. I wasn't fond of repeating the expiration check pattern, and
also it meant the culling worker could see different things than the
timer.
Moving everything in the worker does however mean we can get rid of the new
worker_pool.idle_cull_list, which is my least favourite bit of that
approach, so I'll give that a try.
> If that
> bothers you, we can make workers keep track of the oldest idle's timestamp
> in, say, wq->first_idle_at as the workers go idle and busy and then the
> timer can simply look at the value and decide to schedule the work item or
> not.
>
I don't think the overhead at worker_{enter,leave}_idle() would be worth it.
> Thanks.
>
> --
> tejun
Powered by blists - more mailing lists