From mboxrd@z Thu Jan 1 00:00:00 1970 From: Keir Fraser Subject: Re: freezing of kernel threads Date: Thu, 22 Nov 2012 12:38:22 +0000 Message-ID: References: <50AE18CA02000078000AA90F@nat28.tlf.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <50AE18CA02000078000AA90F@nat28.tlf.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich , Konrad Rzeszutek Wilk Cc: xen-devel List-Id: xen-devel@lists.xenproject.org On 22/11/2012 11:21, "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())? 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 >