On 9/26/2018 2:53 PM, Tejun Heo wrote:
Hello,
On Wed, Sep 26, 2018 at 02:51:38PM -0700, Alexander Duyck wrote:
quoted
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: Alexander Duyck <redacted>
Why not just use unbound workqueues, which are NUMA-affine by default?
Are there big enough advantages?
Thanks.
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 copies the logic of "queue_work_on" with the exception that I am doing a check to verify that there is an intersection between wq_unbound_cpumask and the cpumask of the node, and then passing a CPU from that intersection into "__queue_work".
Thanks.
- Alex