All of lore.kernel.org
 help / color / mirror / Atom feed
From: Valentin Schneider <vschneid@redhat.com>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>, Tejun Heo <tj@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Frederic Weisbecker <frederic@kernel.org>,
	Juri Lelli <juri.lelli@redhat.com>, Phil Auld <pauld@redhat.com>,
	Marcelo Tosatti <mtosatti@redhat.com>
Subject: Re: [RFC PATCH v2 1/2] workqueue: Unbind workers before sending them to exit()
Date: Thu, 28 Jul 2022 11:54:19 +0100	[thread overview]
Message-ID: <xhsmhedy5ecdg.mognet@vschneid.remote.csb> (raw)
In-Reply-To: <CAJhGHyCeraX1jcea9kt_FBC561zBgECuw5qx8TAdCG0EHnT6kA@mail.gmail.com>

On 28/07/22 01:13, Lai Jiangshan wrote:
> Quick review before going to sleep.
>

Thanks!

> On Wed, Jul 27, 2022 at 7:54 PM Valentin Schneider <vschneid@redhat.com> wrote:
>> @@ -1806,8 +1806,10 @@ static void worker_enter_idle(struct worker *worker)
>>         /* idle_list is LIFO */
>>         list_add(&worker->entry, &pool->idle_list);
>>
>> -       if (too_many_workers(pool) && !timer_pending(&pool->idle_timer))
>> -               mod_timer(&pool->idle_timer, jiffies + IDLE_WORKER_TIMEOUT);
>> +       if (too_many_workers(pool) && !delayed_work_pending(&pool->idle_reaper_work))
>> +               mod_delayed_work(system_unbound_wq,
>> +                                &pool->idle_reaper_work,
>> +                                IDLE_WORKER_TIMEOUT);
>
> system_unbound_wq doesn't have a rescuer.
>
> A new workqueue with a rescuer needs to be created and used for
> this purpose.
>

Right, I think it makes sense for those work items to be attached to a
WQ_MEM_RECLAIM workqueue. Should I add that as a workqueue-internal
thing?

>>
>>         /* Sanity check nr_running. */
>>         WARN_ON_ONCE(pool->nr_workers == pool->nr_idle && pool->nr_running);
>> @@ -1972,9 +1974,29 @@ static struct worker *create_worker(struct worker_pool *pool)
>>         return NULL;
>>  }
>>
>> +static void unbind_worker(struct worker *worker)
>> +{
>> +       kthread_set_per_cpu(worker->task, -1);
>> +       WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, wq_unbound_cpumask) < 0);
>> +}
>> +
>> +static void rebind_worker(struct worker *worker, struct worker_pool *pool)
>> +{
>> +       kthread_set_per_cpu(worker->task, pool->cpu);
>> +       WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, pool->attrs->cpumask) < 0);
>> +}
>> +
>> +static void reap_worker(struct worker *worker)
>> +{
>> +       list_del_init(&worker->entry);
>> +       unbind_worker(worker);
>> +       wake_up_process(worker->task);
>
>
> Since WORKER_DIE is set, the worker can be possible freed now
> if there is another source to wake it up.
>

My understanding for having reap_worker() be "safe" to use outside of
raw_spin_lock_irq(pool->lock) is that pool->idle_list is never accessed
outside of the pool->lock, and wake_up_worker() only wakes a worker that
is in that list. So with destroy_worker() detaching the worker from
pool->idle_list under pool->lock, I'm not aware of a codepath other than
reap_worker() that could wake it up.

The only wake_up_process() I see that doesn't involve the pool->idle_list
is in send_mayday(), but AFAIA rescuers can never end up in the idle_list
and are specifically destroyed in destroy_workqueue().

> I think reverting a part of the commit 60f5a4bcf852("workqueue:
> async worker destruction") to make use of kthread_stop()
> in destroy_worker() should be a good idea.


  reply	other threads:[~2022-07-28 10:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-27 11:53 [RFC PATCH v2 0/2] workqueue: destroy_worker() vs isolated CPUs Valentin Schneider
2022-07-27 11:53 ` [RFC PATCH v2 1/2] workqueue: Unbind workers before sending them to exit() Valentin Schneider
2022-07-27 17:13   ` Lai Jiangshan
2022-07-28 10:54     ` Valentin Schneider [this message]
2022-07-28 16:35       ` Tejun Heo
2022-07-28 17:24         ` Valentin Schneider
2022-07-28 17:31           ` Tejun Heo
2022-07-29 10:12             ` Valentin Schneider
2022-07-27 11:53 ` [RFC PATCH v2 2/2] DEBUG: workqueue: kworker spawner Valentin Schneider

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xhsmhedy5ecdg.mognet@vschneid.remote.csb \
    --to=vschneid@redhat.com \
    --cc=frederic@kernel.org \
    --cc=jiangshanlai@gmail.com \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mtosatti@redhat.com \
    --cc=pauld@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tj@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.