From mboxrd@z Thu Jan 1 00:00:00 1970 From: Juergen Gross Subject: Re: [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying Date: Fri, 09 May 2014 07:01:54 +0200 Message-ID: <536C6142.30904@ts.fujitsu.com> References: <1399449149-5531-1-git-send-email-juergen.gross@ts.fujitsu.com> <536A33B5.7000908@ts.fujitsu.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: George Dunlap Cc: "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org On 08.05.2014 17:10, George Dunlap wrote: > On Wed, May 7, 2014 at 2:23 PM, Juergen Gross > wrote: >> On 07.05.2014 15:10, George Dunlap wrote: >>> >>> On Wed, May 7, 2014 at 8:52 AM, Juergen Gross >>> wrote: >>>> >>>> When a cpupool is destroyed just after the last domain has been stopped >>>> the >>>> domain might already be removed from the cpupool without having >>>> decremented >>>> the domain count of the cpupool. This will result in rejection of the >>>> cpupool-destroy operation. >>> >>> >>> I'm a bit confused. What's the sched_move_domain() for, then? If >>> we're going to handle "dying domains" by doing a retry, could we just >>> get rid of it? >> >> >> The sched_move_domain() is still needed for cases where a domain stays >> dying for a longer time, e.g. when a dom0 process is still referencing >> some of it's memory pages. This may be a rare situation, but being unable >> to use a physical cpu for another cpupool just because of this case is >> worse than this little piece of code, IMO. > > And I take it there are times when the move fails for whatever reason? ENOMEM for example. > Could you add a comment explaining this above the for() loop then, for > posterity? Could you define 'this', please? The reason for the sched_move_domain() is mentioned in the head comment of the function (zombie domains). The possibility of a failing sched_move_domain() is obvious by the return value checking. Juergen -- Juergen Gross Principal Developer Operating Systems PSO PM&D ES&S SWE OS6 Telephone: +49 (0) 89 62060 2932 Fujitsu e-mail: juergen.gross@ts.fujitsu.com Mies-van-der-Rohe-Str. 8 Internet: ts.fujitsu.com D-80807 Muenchen Company details: ts.fujitsu.com/imprint.html