Re: [PATCH 1/3] power, vfs: move away from PF_KTHREAD freezing in favor of fs freezing

[Jiri Kosina]

On Mon, 2 Nov 2015, yalin wang wrote:

> do you test your patch on kthread_bind()  kernel thread ?
> if you remove freeze_kernel_threads() function,
> this means lots of pthread will be running status during suspend .

pthreads? Again, userspace is frozen by that time.

> will have problem for bind thread , these thread will be migrate to other 
> CPU , will have problem running code on other CPU, another problems is 
> that the cpu_allowed_ptr is changed and will never be restore to original CPU mask .

Hmm, shouldn't that be fixed instead?

I mean, select_fallback_rq() will surely force a rq outside of the 
cpus_allowed if needed. I can imagine kthread bound to a particular CPU 
either wanting to keep itself affine to that CPU (and be scheduled out 
until CPU becomes online again), or it might want to actually be forced to 
another CPU and migrated back once "its own" CPU becomes available again.

But then yes, indeed, at the end of the day this is more or less what 
try_to_freeze() gives you. Fair enough, this might be one of cases where 
freezer for kthreads is actually useful (and would need to be documented 
to provide this semantics).

kthread CPU binding seems to be used by ~7 kthreads altogether in the 
kernel. Funily enough, quite some of them do not call try_to_freeze() at 
all. Which just demonstrates my point regarding how messy the current 
state of affairs is.

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/