From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eunbyung Park Subject: Re: deadlock in the credit2 Date: Sat, 15 Oct 2011 13:48:32 +0900 Message-ID: <4E9910A0.5030002@gmail.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Keir Fraser Cc: George Dunlap , xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org >>> if ( d == current->domain ) >>> vcpu_schedule_lock_irq(current); >>> >>> It was very hard to understan for me..:) What does it exactly mean? >> You're asking what "current" means? "current" is a macro that always >> resolves to the vcpu which is running on the current processor. >> >> sched_adjust() seems to be trying to avoid scheduling races in general >> by pausing all vcpus before calling the per-scheduler function. But >> if a VM is calling the op on itself, the vcpu making the hypercall >> can't pause itself. So in that case (current->domain == d) will be >> true, so sched_adjust() grab the schedule lock of that vm instead. >> >> But really all that locking should be handled in the scheduler >> function, not by the generic code. It knows best what needs to be >> locked when. This was what I really wanted to ask about. Now I can understand what the generic scheduler code was going to say. Thanks for your kindness. -- Best Regards, Eunbyung Park