[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170322134304.GG2360@aaronlu.sh.intel.com>
Date: Wed, 22 Mar 2017 21:43:04 +0800
From: Aaron Lu <aaron.lu@...el.com>
To: Minchan Kim <minchan@...nel.org>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Dave Hansen <dave.hansen@...el.com>,
Tim Chen <tim.c.chen@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Ying Huang <ying.huang@...el.com>
Subject: Re: [PATCH v2 3/5] mm: use a dedicated workqueue for the free workers
On Wed, Mar 22, 2017 at 05:55:12PM +0900, Minchan Kim wrote:
> On Wed, Mar 22, 2017 at 04:41:04PM +0800, Aaron Lu wrote:
> > My understanding of the unbound workqueue is that it will create a
> > thread pool for each node, versus each CPU as in the bound workqueue
> > case, and use threads from the thread pool(create threads if not enough)
> > to do the work.
>
> Yes, that was my understand so I read code and found that
>
> insert_work:
> ..
> if (__need_more_worker(pool))
> wake_up_worker(pool);
>
> so I thought if there is a running thread in that node, workqueue
> will not wake any other threads so parallelism should be max 2.
> AFAIK, if the work goes sleep, scheduler will spawn new worker
> thread so the active worker could be a lot but I cannot see any
> significant sleepable point in that work(ie, batch_free_work).
Looks like worker_thread() will spawn new worker through manage_worker().
Note that pool->nr_running will always be zero for an unbound workqueue
and thus need_more_worker() will return true as long as there are queued
work items in the pool.
Thanks,
Aaron
Powered by blists - more mailing lists