lkml.org 
[lkml]   [2015]   [Nov]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] power, vfs: move away from PF_KTHREAD freezing in favor of fs freezing
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



\
 
 \ /
  Last update: 2015-11-02 12:21    [W:0.150 / U:0.904 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site