LFS and Xen3 testing

yamtmwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:

>> I've just recently discovered something
interesting with Xen3 that
>> might be related: if the dom0 is running something
that spins the CPU
>> (like "perl -e '1 while 1'" or
"yes > /dev/null") the NetBSD domU will
>> not be run at all; it won't respond to the console
nor to network
>> traffic, and its timer event handler won't be
called.  A Linux domU
>> doesn't appear to have the same problem.
>
> it's a characteristic of the default setting of sedf
scheduler.
> are you sure it doesn't happen for linux domU?

The Linux domU is definitely affected, but it's still able
to answer
pings (if a bit slowly), while the NetBSD one doesn't
answer any until
the dom0 stops hogging the CPU.

However, I see what you mean about the default scheduling
parameters,
I think -- giving the domU a nonzero minimum timeslice fixes
this.

-- 
(let ((C call-with-current-continuation)) (apply (lambda (x
y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s)
l))))))  (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car
l)) ((f (cdr l))
(C k)))))))    '((#\J #\d #\D #\v #\s) (#\e #\space
#\a #\i #\newline)))))

On Tue, Sep 12, 2006 at 07:32:48PM -0400, Jed Davis wrote:
> yamtmwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> 
> >> I've just recently discovered something
interesting with Xen3 that
> >> might be related: if the dom0 is running
something that spins the CPU
> >> (like "perl -e '1 while 1'" or
"yes > /dev/null") the NetBSD domU will
> >> not be run at all; it won't respond to the
console nor to network
> >> traffic, and its timer event handler won't be
called.  A Linux domU
> >> doesn't appear to have the same problem.
> >
> > it's a characteristic of the default setting of
sedf scheduler.
> > are you sure it doesn't happen for linux domU?
> 
> The Linux domU is definitely affected, but it's still
able to answer
> pings (if a bit slowly), while the NetBSD one doesn't
answer any until
> the dom0 stops hogging the CPU.
> 
> However, I see what you mean about the default
scheduling parameters,
> I think -- giving the domU a nonzero minimum timeslice
fixes this.

Maybe it's a hard interrupts vs soft interrupt issue ? E.g.
hard interrupts
still running but soft interrupts not running when no time
is allocated
to the domU ?

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Tue, Sep 12, 2006 at 07:32:48PM -0400, Jed Davis wrote:
> yamtmwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> 
> >> I've just recently discovered something
interesting with Xen3 that
> >> might be related: if the dom0 is running
something that spins the CPU
> >> (like "perl -e '1 while 1'" or
"yes > /dev/null") the NetBSD domU will
> >> not be run at all; it won't respond to the
console nor to network
> >> traffic, and its timer event handler won't be
called.  A Linux domU
> >> doesn't appear to have the same problem.
> >
> > it's a characteristic of the default setting of
sedf scheduler.
> > are you sure it doesn't happen for linux domU?
> 
> The Linux domU is definitely affected, but it's still
able to answer
> pings (if a bit slowly), while the NetBSD one doesn't
answer any until
> the dom0 stops hogging the CPU.
> 
> However, I see what you mean about the default
scheduling parameters,
> I think -- giving the domU a nonzero minimum timeslice
fixes this.

Maybe it's a hard interrupts vs soft interrupt issue ? E.g.
hard interrupts
still running but soft interrupts not running when no time
is allocated
to the domU ?

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--