On Mon Jul 4 09:14:10 EDT 2011, st...@quintile.net wrote:
> > so why don't you just give your plan 9 guest 1 processor, either through
> > the vmm
> > or *ncpu, and be done with it?
>
> Too much work to port plan9 a cpu server to the mac ppc hardware... :-)
>
> An intel mac would solve many pro
I appologise for the noise, got my emails very confused.
-Steve
> so why don't you just give your plan 9 guest 1 processor, either through the
> vmm
> or *ncpu, and be done with it?
Too much work to port plan9 a cpu server to the mac ppc hardware... :-)
An intel mac would solve many problems I agree.
-Steve
> I am aware of the latency issue there but in my case i care much more
> about the battery of my host than about responsiveness of the guest.
so why don't you just give your plan 9 guest 1 processor, either through the vmm
or *ncpu, and be done with it?
- erik
Indeed, there's an assumption that each core manages the TLB by
examining the data structures at clock frequency. In a halt,
the clock interrupts still happen so I guess there's no need to
invalidate the TLBs just before halt.
You could set a variable indicating you're halted and cause other
core
On Fri, 1 Jul 2011 19:23:03 +0200
erik quanstrom wrote:
> suppose that i have a multicore machine and all maches
> have executed halt(). then, if i get an interrupt on one that
> causes a proc to be ready, then i have to wait until the next
> clock tick to sched() it on any other core. this is
On i386 systems with MONITOR/MWAIT, you could use them; simpler than
adding support for IPIs, I imagine.
-- vs
On Fri, 01 Jul 2011 14:01:28 EDT erik quanstrom wrote:
> >
> > interprocessor interrupts are the obvious solution
> > but no one has bothered to implement them.
> >
>
> i almost mentioned this, and it's on my list. i just haven't
> had the time. it turns out that a naive implementation of
>
>
> interprocessor interrupts are the obvious solution
> but no one has bothered to implement them.
>
i almost mentioned this, and it's on my list. i just haven't
had the time. it turns out that a naive implementation of
ipi'ing 1 proc per wakeup will have to watch out for the
same races that
On Fri, Jul 1, 2011 at 1:47 PM, Ali Mashtizadeh wrote:
> The hlt instruction on x86 leaves the halt state after an external
> interrupt is fired. I'm not sure why you think it doesn't work?
he didn't say it didn't work.
he said it required waiting for the next interrupt,
of which the only guarant
The hlt instruction on x86 leaves the halt state after an external
interrupt is fired. I'm not sure why you think it doesn't work? If you
need to wake up other cores then you may need IPIs is that what you
mean?
~ Ali
On Fri, Jul 1, 2011 at 10:23 AM, erik quanstrom wrote:
> On Fri Jul 1 13:06:3
On Fri Jul 1 13:06:36 EDT 2011, henn...@plan9.bell-labs.com wrote:
> in pc/main.c idlehands() the kernel decides to release the CPU only
> when you are not running a multicore kernel. As a result there is only
> busy waiting. Unfortunately there is no hint telling why we do not let
> the CPU rest
Hi,
in pc/main.c idlehands() the kernel decides to release the CPU only
when you are not running a multicore kernel. As a result there is only
busy waiting. Unfortunately there is no hint telling why we do not let
the CPU rest a little.
> void
> idlehands(void)
> {
> if(conf.nmach == 1)
>
13 matches
Mail list logo
