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
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 >
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 >
>>> 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