On Tue, Jun 16, 2009 at 02:59:54PM -0400, Luke S Crawford wrote: > Bill McGonigle <bill at bfccomputing.com> writes: > > > On 06/15/2009 11:33 PM, Luke S Crawford wrote: > > > xm sched-credit -d 0 60000 > > > > Ah, ha! This appears to work. I didn't need to reserve a CPU for the > > dom0 (knock on wood). Much obliged, Luke. > > > > I'm academically curious, though - I seem to have created a CPU deadlock > > of some sort, yet in 'xm top' none of the CPU's were pegged. I've got > > no reason to not give dom0 utmost priority - that makes perfect sense to > > me - but I'm surprised the Xen scheduler would allow me to get into this > > situation by default. > > > My understanding of this is entirely janitor-level, but I believe what you > are seeing is that the dom0 has exhausted it's 'credits' and so if a > DomU wants the CPU the dom0 gets kicked off the cpu, waits a timeslice > (I think timeslices are on the order of tens of millaseconds... I've > read 60ms, which is quite a long time in terms of sending a packet to a > nearby storage box.) then gets back on the CPU. > afaik Xen credit scheduler assigns/changes credits every 30ms. although CPU scheduling happens more often? -- Pasi