Re: [PATCH] cpupools: retry cpupool-destroy if domain in cpupool is dying

[Juergen Gross <juergen.gross@ts.fujitsu.com>]

On 08.05.2014 17:10, George Dunlap wrote:
> On Wed, May 7, 2014 at 2:23 PM, Juergen Gross
> <juergen.gross@ts.fujitsu.com> wrote:
>> On 07.05.2014 15:10, George Dunlap wrote:
>>>
>>> On Wed, May 7, 2014 at 8:52 AM, Juergen Gross
>>> <juergen.gross@ts.fujitsu.com> 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