From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mukesh Rathor Subject: Re: dom0 hang Date: Tue, 07 Jul 2009 11:28:25 -0700 Message-ID: <4A5393C9.6020605@oracle.com> References: Reply-To: mukesh.rathor@oracle.com 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 , "Kurt C. Hackel" , "Tian, Kevin" , "xen-devel@lists.xensource.com" , "Yu, Ke" List-Id: xen-devel@lists.xenproject.org Keir Fraser wrote: > On 07/07/2009 08:14, "Yu, Ke" wrote: > >>> BTW, why can't the tick be suspended when csched_schedule() concludes >>> it's idle vcpu before returning? won't that would make it less intrusive. >> The tick suspend can be put in csched_schedule, but the suspend/resume logic >> is still needed in acpi_processor_idle anyway, due to another dbs_timer >> suspend/resume. The intention here is to make acpi_processor_idle the central >> place for timers which are stoppable during idle period. If there is other >> stoppable timer in the future, it can be easily added to acpi_processor_idle. >> So it is clean to keep current logic. and as long as we carefully not over >> doing the softirq, it looks not so intrusive. How do you think? > > I think the approach is fine. I also already applied your patch since it is > obviously a good bug fix, even if it doesn't fix Mukesh's bug. And I fixed > the comment at the same time. And I backported it for Xen 3.4.1. > > -- Keir > It fixes my bug. Thanks, Mukesh