On 10/2/2018 11:41 AM, Tejun Heo wrote:
Hello,
On Tue, Oct 02, 2018 at 11:23:26AM -0700, Alexander Duyck wrote:
Yeah, it's all in wq_select_unbound_cpu(). Right now, if the
requested cpu isn't in wq_unbound_cpumask, it falls back to dumb
round-robin. We can probably do better there and find
Hello,
On Tue, Oct 02, 2018 at 11:23:26AM -0700, Alexander Duyck wrote:
> >Yeah, it's all in wq_select_unbound_cpu(). Right now, if the
> >requested cpu isn't in wq_unbound_cpumask, it falls back to dumb
> >round-robin. We can probably do better there and find the nearest
> >node considering
On 10/2/2018 10:41 AM, Tejun Heo wrote:
Hello,
On Mon, Oct 01, 2018 at 02:54:39PM -0700, Alexander Duyck wrote:
It might be better to leave queue_work_on() to be used for per-cpu
workqueues and introduce queue_work_near() as you suggseted. I just
don't want it to duplicate the node selection
Hello,
On Mon, Oct 01, 2018 at 02:54:39PM -0700, Alexander Duyck wrote:
> >It might be better to leave queue_work_on() to be used for per-cpu
> >workqueues and introduce queue_work_near() as you suggseted. I just
> >don't want it to duplicate the node selection code in it. Would that
> >work?
>
On 10/1/2018 9:01 AM, Tejun Heo wrote:
Hello,
On Wed, Sep 26, 2018 at 03:19:21PM -0700, Alexander Duyck wrote:
On 9/26/2018 3:09 PM, Tejun Heo wrote:
I could just use queue_work_on probably, but is there any issue if I
am passing CPU values that are not in the wq_unbound_cpumask? That
That
Hello,
On Wed, Sep 26, 2018 at 03:19:21PM -0700, Alexander Duyck wrote:
> On 9/26/2018 3:09 PM, Tejun Heo wrote:
> I could just use queue_work_on probably, but is there any issue if I
> am passing CPU values that are not in the wq_unbound_cpumask? That
That should be fine. If it can't find any
On 9/26/2018 3:09 PM, Tejun Heo wrote:
Hello,
On Wed, Sep 26, 2018 at 03:05:17PM -0700, Alexander Duyck wrote:
I am using unbound workqueues. However there isn't an interface that
exposes the NUMA bits of them directly. All I am doing with this
patch is adding "queue_work_near" which takes a
Hello,
On Wed, Sep 26, 2018 at 03:05:17PM -0700, Alexander Duyck wrote:
> I am using unbound workqueues. However there isn't an interface that
> exposes the NUMA bits of them directly. All I am doing with this
> patch is adding "queue_work_near" which takes a NUMA node as an
> argument and then
On 9/26/2018 2:53 PM, Tejun Heo wrote:
Hello,
On Wed, Sep 26, 2018 at 02:51:38PM -0700, Alexander Duyck wrote:
This patch provides a new function queue_work_near which is meant to
schedule work on the nearest unbound CPU to the requested NUMA node. The
main motivation for this is to help
Hello,
On Wed, Sep 26, 2018 at 02:51:38PM -0700, Alexander Duyck wrote:
> This patch provides a new function queue_work_near which is meant to
> schedule work on the nearest unbound CPU to the requested NUMA node. The
> main motivation for this is to help assist asynchronous init to better
>
This patch provides a new function queue_work_near which is meant to
schedule work on the nearest unbound CPU to the requested NUMA node. The
main motivation for this is to help assist asynchronous init to better
improve boot times for devices that are local to a specific node.
Signed-off-by:
11 matches
Mail list logo
