From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 4 Jul 2011 11:24:20 +0200 From: Henning Schild To: "9fans@9fans.net" <9fans@9fans.net> Message-ID: <20110704112420.16237b22@leffe.cs.bell-labs.com> In-Reply-To: <83656e84a9290648e03a7e880786e132@ladd.quanstro.net> References: <20110701160026.0db036cd@leffe.cs.bell-labs.com> <83656e84a9290648e03a7e880786e132@ladd.quanstro.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [9fans] why not halt in x86 multicore Topicbox-Message-UUID: fa41c916-ead6-11e9-9d60-3106f5b1d025 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 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