freezing of kernel threads

freezing of kernel threads

[Jan Beulich]

Keir,

in linux-2.6.18-xen.hg c/s 74:cb50d25a9468 you made blktap
match blkback in calling try_to_freeze() from the main thread loop.
Threads in other drivers didn't get changed, though. Is there a
particular reason why only block, and only backend, threads are in
need of this (the only other one using it is xenfb_thread())?

Konrad, as of 2.6.23 kernel threads are non-freezable by default,
i.e. xen-blkback calling try_to_freeze() is completely pointless
without a prior call to set_freezable(). Also, in case the latter is to
be added, switching to wait_event_freezable() instead of the
direct use of try_to_freeze() might be the right way to go.

Jan

Re: freezing of kernel threads

[Keir Fraser]

On 22/11/2012 11:21, "Jan Beulich" <JBeulich@suse.com> wrote:

> Keir,
> 
> in linux-2.6.18-xen.hg c/s 74:cb50d25a9468 you made blktap
> match blkback in calling try_to_freeze() from the main thread loop.
> Threads in other drivers didn't get changed, though. Is there a
> particular reason why only block, and only backend, threads are in
> need of this (the only other one using it is xenfb_thread())?

I don't really recall. I expect someone pointed out the difference between
the two drivers and so I added the call to blktap. Back then I don't know
that any of our other drivers had kthreads?

 -- Keir

> Konrad, as of 2.6.23 kernel threads are non-freezable by default,
> i.e. xen-blkback calling try_to_freeze() is completely pointless
> without a prior call to set_freezable(). Also, in case the latter is to
> be added, switching to wait_event_freezable() instead of the
> direct use of try_to_freeze() might be the right way to go.
> 
> Jan
> 

Re: freezing of kernel threads

[Konrad Rzeszutek Wilk]

On Thu, Nov 22, 2012 at 11:21:30AM +0000, Jan Beulich wrote:
> Keir,
> 
> in linux-2.6.18-xen.hg c/s 74:cb50d25a9468 you made blktap
> match blkback in calling try_to_freeze() from the main thread loop.
> Threads in other drivers didn't get changed, though. Is there a
> particular reason why only block, and only backend, threads are in
> need of this (the only other one using it is xenfb_thread())?
> 
> Konrad, as of 2.6.23 kernel threads are non-freezable by default,
> i.e. xen-blkback calling try_to_freeze() is completely pointless
> without a prior call to set_freezable(). Also, in case the latter is to
> be added, switching to wait_event_freezable() instead of the
> direct use of try_to_freeze() might be the right way to go.

OK, any idea why the need to be come freezable was added in? Just
for power suspend/resume?

> 
> Jan
> 

Re: freezing of kernel threads

[Jan Beulich]

>>> On 27.11.12 at 17:47, Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> wrote:
> On Thu, Nov 22, 2012 at 11:21:30AM +0000, Jan Beulich wrote:
>> Keir,
>> 
>> in linux-2.6.18-xen.hg c/s 74:cb50d25a9468 you made blktap
>> match blkback in calling try_to_freeze() from the main thread loop.
>> Threads in other drivers didn't get changed, though. Is there a
>> particular reason why only block, and only backend, threads are in
>> need of this (the only other one using it is xenfb_thread())?
>> 
>> Konrad, as of 2.6.23 kernel threads are non-freezable by default,
>> i.e. xen-blkback calling try_to_freeze() is completely pointless
>> without a prior call to set_freezable(). Also, in case the latter is to
>> be added, switching to wait_event_freezable() instead of the
>> direct use of try_to_freeze() might be the right way to go.
> 
> OK, any idea why the need to be come freezable was added in? Just
> for power suspend/resume?

No, which is why I had asked Keir (who unfortunately didn't recall
either).

Jan