| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] FreeBSD/Xen ugliness
Kip,
You need to block rather than yield -- if noone else is runnable and
you call yield, Xen will simply continue to run your idle loop rather
than powering down the CPU. If you call block then Xen will *not* run
you until there is some event upcall to be delivered -- this is the
behaviour that you actually want.
You want your idle loop to look something like this:
while ( !<should leave idle loop> ) {
disable_intr();
if ( <should leave idle loop> ) {
enable_intr();
break;
}
if ( HYPERVISOR_set_timer_op(<next timeout>) == 0 )
HYPERVISOR_block();
else
enable_intr();
}
The use of HYPERVISOR_set_time_op() is confusing on first
sight. Recall that you stop getting periodic timer upcalls when your
domain is not running. If you block then you will receive no periodic
upcalls until after the next time you receive some other asynchronous
upcall (which serves to unblock you).
This is bad if the next piece of work your OS needs to execute is
being scheduled off of the timer upcall! What we do in Linux is peek
at the timer subsystem's alarm list, looking for the earliest
requested timeout. We then set a one-shot alarm in Xen that will
wake/unblock us at that point if we were not unblocked already.
-- Keir
> I've seen the same timing issues. We do call yield where appropriate:
>
> static void
> cpu_idle_default(void)
> {
> #if 0
> /*
> * we must absolutely guarentee that hlt is the
> * absolute next instruction after sti or we
> * introduce a timing window.
> */
> __asm __volatile("sti; hlt");
> #endif
> enable_intr();
> HYPERVISOR_yield();
> }
>
>
> So I'm not sure what the problem is. After the 5.3 work and coredump is
> done I might look into it. There may have been some fixes to the clock
> code in the meantime.
>
>
> -Kip
>
>
> On Sat, 8 Jan 2005, Derrik Pates wrote:
>
> > Kip:
> >
> > Well, I have good news; thanks to Darren Tucker pointing out that the
> > boot.netif.* parameters _have_ to be added, I was able to successfully
> > boot your FreeBSD/Xen kernel. It seems to work okay so far. It fairly
> > regularly (every few minutes or so) spits out a line like:
> >
> > Expensive timeout(9) function: 0xc00b0bd0(0) 0.010000854 s
> >
> > at me, but it seems to otherwise behave as FreeBSD should. The only
> > thing I've noticed so far is that, looking at the output of 'xm list',
> > its domain's virtual-time clock seems to grow at a constant rate. I'm
> > guessing this means it doesn't call up to the hypervisor and say "Please
> > schedule someone else, I'm idle right now" when it has nothing to do. It
> > doesn't seem to affect the performance of other domains though, but I
> > thought it worth pointing out. Unfortunately, I don't know enough about
> > FreeBSD's scheduler to make the necessary changes to make this work as
> > it should. I'll have to see about getting a proper full CVS pull of the
> > sys/ tree for 5.2.1 on my FreeBSD install in VMware, and see if I can
> > make a FreeBSD kernel build work; however, I'd like to see the 5.3
> > kernel when you get around to it.
> >
> > --
> > Derrik Pates
> > dpates@xxxxxxxxxx
> >
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home