On Thu, Oct 29 2020 at 03:14, Qiang Zhang wrote:
> Really, this patch is not considered that work may be put into the
> queue after the bound CPU is offline. in addition, when the bound CPU
> goes online again, before restoring the worker's CPU affinity, work
> may be put into the queue.
And how is that supposed to be correct?
> Although int this (powerclamp) way，that's not a problem, that it is
> solved by destroying and creating tasks when the CPU hotplug, in
> addition, when CPU going down , this need call 'cancel_work_sync' func
> in offline callback, this may be blocked long time. these operation is
> expensive.
It does not matter whether it's expensive or not. It's correct and
that's what matters most.
> this patch only just to recover the worker task's affinity when CPU go
> to online again that create by "kthread_create_worker_on_cpu" func ,
> likely per-CPU worker method when CPU hotplug in "workqueue" and
> "io-wq".
I know what this patch just does, but that makes it not any more
correct. It creates a semanticaly ill defined illusion of correctness.
We are not "fixing" a problem by making it work for your particular and
even not explained use case.
The expected semantics of a cpu bound kthread_worker are completely
unclear and undocumented. This needs to be fixed first and once this is
established and agreed on then the gaps in the implementation can be
closed.
Thanks,
tglx
