From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Jan Beulich" Subject: Re: Linux balloon driver stops accepting target_kb for a long time Date: Tue, 24 Aug 2010 08:45:10 +0100 Message-ID: <4C7394A60200007800011D5D@vpn.id2.novell.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: Content-Disposition: inline List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Dan Magenheimer Cc: jeremy@goop.org, xen-devel@lists.xensource.com, Keir Fraser List-Id: xen-devel@lists.xenproject.org >>> On 24.08.10 at 00:45, Dan Magenheimer = wrote: > Reviewing code, one thing caught my attention. In balloon_process(), > the balloon_mutex is down'ed then, under certain conditions > schedule() is called with the balloon_mutex still held and without > another timer set. Any chance this could be a problem, especially > if another kernel thread invokes balloon_set_new_target()? > If so, what might finally kick the scheduled-out thread after > 30 minutes to reset the balloon_timer and up the mutex? How could this be a problem? Calling schedule() is a yield, not an indefinite sleep, and hence the loop will resume as soon as there's no higher priority runnable task anymore for a long enough time (obviously very much less than 30 minutes, unless something really odd is running on your box). Furthermore, besides the obvious option of inserting some debug code, I think SysRq-t would also allow you to check whether balloon_process() indeed doesn't exit over a period of minutes. Jan