Yes, I forgot about the reschedule event here, and thus migration is 
scheduled in other schedule points triggered later. Please forget this 
patch. :-)
Thanks
Kevin
>-----Original Message-----
>From: Emmanuel Ackaouy [mailto:ack@xxxxxxxxxxxxx]
>Sent: 2007年1月11日 17:49
>To: Tian, Kevin
>Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
>Subject: Re: [Xen-devel] [PATCH] trivial fix for vcpu_set_affinity
>
>I don't get it.
>
>If you don't at least call vcpu_sleep_nosync() on the current context
>when it changes affinity, how do you initiate a reschedule event?
>
>What's wrong with the code as is?
>
>On Jan 11, 2007, at 9:42, Tian, Kevin wrote:
>
>> No need to try migration in current context since self migrate
>> will be handled by next vcpu after context switch.
>>
>> Signed-off-by Kevin Tian <kevin.tian@xxxxxxxxx>
>>
>> diff -r e66f047bc97e xen/common/schedule.c
>> --- a/xen/common/schedule.c Tue Jan 09 18:56:44 2007 -0800
>> +++ b/xen/common/schedule.c Thu Jan 11 16:31:37 2007 +0800
>> @@ -243,7 +243,7 @@ int vcpu_set_affinity(struct vcpu *v, cp
>>
>> vcpu_schedule_unlock_irqrestore(v, flags);
>>
>> - if ( test_bit(_VCPUF_migrating, &v->vcpu_flags) )
>> + if ( (v != current) && test_bit(_VCPUF_migrating,
>&v->vcpu_flags)
>> )
>> {
>> vcpu_sleep_nosync(v);
>> vcpu_migrate(v);
>>
>> Thanks,
>> Kevin
>>
><set_affinity.patch>__________________________________________
>_____
>> Xen-devel mailing list
>> Xen-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-devel 
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel