From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rikiya Ayukawa Subject: Re: [PATCH][RFC] making "xm dump-core" paralell Date: Thu, 27 Sep 2007 17:36:23 +0900 Message-ID: <46FB6B87.4000204@np.css.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: John Levon Cc: xen-devel@lists.xensource.com, Akio Takebe , SUZUKI Kazuhiro List-Id: xen-devel@lists.xenproject.org Hi, # Sorry, I mistook the function name on e-mail. # xc_domain_dump() -> xc_domain_dumpcore() > - Add xc_dumpcore program. This program only calls xc_domain_dump() > > in libxc to dump the core image of a domainU. > > > Why? To make xend call indirectly xc_domain_dumpcore() written by C. I think this is similar to xc_save and xc_restore programs. xend (cset#15880:a00cc97b392a) calls xc_domain_dumpcore() directly. It takes xend a lot of time to finish this C function. Until the xend's thread finishes xc_domain_dumpcore(), any other xend's thread don't run because of GIL (global interpreter lock) in CPython specification. http://docs.python.org/api/threads.html # If xc_domain_dumpcore() release GIL sometimes, other xend's thread can run. # But I guess not. By changing xend to create a xc_dumpcore process and to wait for the process to finish, xend don't begin to call C function directly, so that other xend's thread can run while dealing with dump-core. Thank you, Rikiya Ayukawa