WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-ia64-devel

RE: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU

To: "Atsushi SAKAI" <sakaia@xxxxxxxxxxxxxx>, "Tristan Gingold" <Tristan.Gingold@xxxxxxxx>, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx>
Subject: RE: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Wed, 5 Jul 2006 21:25:42 +0800
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Wed, 05 Jul 2006 06:26:19 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-ia64-devel-request@lists.xensource.com?subject=help>
List-id: Discussion of the ia64 port of Xen <xen-ia64-devel.lists.xensource.com>
List-post: <mailto:xen-ia64-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-ia64-devel>, <mailto:xen-ia64-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AcagMeyE7Qgtrn8TTs+PZ9dVhOJjrQAAvDIA
Thread-topic: [Xen-ia64-devel] [PATCH] emulate PAL_HALT_LIGHT on domU
>From: Atsushi SAKAI
>Sent: 2006年7月5日 20:51
>
>Hi, Tristan.
>
>(just change the word from scheduler to timer,
> and add code links, sorry for disturbing you.)
>
>I have no idea without changing the linux timer code.
>I also want to know the idea to solve your problem.

Some immediate thoughts:-)

It's possible to address such issue partially with some help from 
scheduler, like to ensure each vcpu scheduled at least once within fixed 
epoch. This however imposes more context switches overhead and 
scalability issue, which also depends on the reason of block state. If 
block is triggered by scenario in your patch (halt), it can be brought back 
more timely like your approach. However if block is caused by some 
synchronization event like I/O emulation for unmodified domain, 
whatever scheduler helps can't really help before I/O emulation is 
completed.

Eddie ever had an experiment on VTI domain to increment vITC 
gradually with a jump limitation, which can also help such issue obviously 
or similar device time out concern.

However above approaches are only meaningful for normal unpaused 
state. For pause/unpause or even save/restore case, it's really welcomed 
to have guest's cooperation either on basic timer logic or on some timer 
service like NTP to catch up wallclock time.

Thanks,
Kevin
>
>If the linux stops over 10 seconds, it appears.
>On Xen, that problem is common in x86/VTx, IA64/noVTI and VTI.
>
>soft lockup code:
>https://www.codeblog.org/gonzui/markup/linux-2.6.16.18/kernel/softlock
>up.c?q=package%3Alinux-2.6.16.18+fundef%3Asoftlockup_tick#l47
>
>Thanks,
>Atsushi SAKAI
>
>
>>I have a question related to the timer.
>>
>>If you pause/unpause a domain for more than 10 secs the softlock
>watchdog is
>>trigerred.  It seems to be harmless but not very elegant.
>>
>>What are the possible solutions apart disabling the softlock watchdog ?
>>
>>Tristan.
>>
>
>
>
>_______________________________________________
>Xen-ia64-devel mailing list
>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>http://lists.xensource.com/xen-ia64-devel

_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel