Comment 3 for bug 1948639

Reviewed: https://review.opendev.org/c/starlingx/kernel/+/815226
Committed: https://opendev.org/starlingx/kernel/commit/cfe452afa565d00ddda817f8f1d0d8bb28da7773
Submitter: "Zuul (22348)"
Branch: master

commit cfe452afa565d00ddda817f8f1d0d8bb28da7773
Author: Jiping Ma <email address hidden>
Date: Mon Oct 25 03:25:01 2021 -0400

    workqueue: Affine rescuer threads and unbound wqs

    This commit ensures that workqueue rescuer threads are affined to the
    platform CPUs specified by the "kthread_cpus" kernel argument. Prior
    to this commit, rescuer threads could be bound to any CPU. Rescuer
    threads are described in "kernel/workqueue.c" as follows:

    "Regular work processing on a pool may block trying to create a new
    worker which uses GFP_KERNEL allocation which has slight chance of
    developing into deadlock if some works currently on the same queue
    need to be processed to satisfy the GFP_KERNEL allocation. This is
    the problem rescuer solves.

    When such condition is possible, the pool summons rescuers of all
    workqueues which have works queued on the pool and let them process
    those works so that forward progress can be guaranteed."

    This commit also affines unbound workqueues to the platform CPUs instead
    of the housekeeping CPUs, because the latter can be a superset of the
    former.

    Verification:
    Compared the affinity of workqueue thread between before and after the
    fix, the affinity was 0xff before this commit that mean the thread
    could be bound to cpu0-7, the affinity was 0x3 after the fix with
    "kthread_cpus=0, 1", which only could be bound to cpu0, 1. Also checked
    unbound workqueue such as "writeback" whose affinity also was 0x3 with
    "kthread_cpus=0, 1". We did not find the commit break anything else.

    Closes-Bug: #1948639

    Signed-off-by: M. Vefa Bicakci <email address hidden>
    Signed-off-by: Jiping Ma <email address hidden>
    Change-Id: I8afd56c8d0d0526d523accf3ea45ee02635b1602