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-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
