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
cores to send an interprocessor interrupt when a process gets
activated. On the other hand, the non-halted cores will also
run the scheduler and pick up any recently readied process.
Sape
--- Begin Message ---
On Fri, 1 Jul 2011 19:23:03 +0200
erik quanstrom <[email protected]> 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 going to be a
> huge performance hit, especially if you are using a 100hz clock
> as the distribution does. for me a potential latency on the order
> of 1-10ms is not going to cut it.
>
> there are a number of potential solutions to this that i'd like to
> try, but i haven't had any time yet.
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 far letting it halt() works fine for me. I guess i could run into
some fun caused by missing TLB invalidation if i used that kernel on a
"real" machine. As far as i know plan9 signals the need for TLB
invalidation through a datastructure. Assuming that everybody polls
with their clock frequency.
So i guess to get it right i will have to clear the TLBs after a
halt(). Right?
Henning
--- End Message ---
