From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net Date: Mon, 4 Jul 2011 11:54:17 +0200 From: Sape Mullender Message-ID: In-Reply-To: <20110704112420.16237b22@leffe.cs.bell-labs.com> References: <20110701160026.0db036cd@leffe.cs.bell-labs.com> <83656e84a9290648e03a7e880786e132@ladd.quanstro.net> <20110704112420.16237b22@leffe.cs.bell-labs.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="upas-ihhbvfktspkirdhouydzoffbwn" Subject: Re: [9fans] why not halt in x86 multicore Topicbox-Message-UUID: fa4614e4-ead6-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --upas-ihhbvfktspkirdhouydzoffbwn Content-Disposition: inline Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit 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 --upas-ihhbvfktspkirdhouydzoffbwn Content-Type: message/rfc822 Content-Disposition: inline Received: from plan9.cs.bell-labs.com ([135.104.9.78]) by plan9; Mon Jul 4 11:26:33 CES 2011 Received: from mail.9fans.net ([67.207.142.3]) by plan9; Mon Jul 4 05:26:31 EDT 2011 Received: from localhost ([127.0.0.1] helo=[67.207.142.3]) by mail.9fans.net with esmtp (Exim 4.71) (envelope-from <9fans-bounces@9fans.net>) id 1QdfnJ-0002tO-3M; Mon, 04 Jul 2011 09:50:21 +0000 Received: from plan9.cs.bell-labs.com ([204.178.31.2]) by mail.9fans.net with esmtp (Exim 4.71) (envelope-from ) id 1QdfnH-0002tJ-Fn for 9fans@9fans.net; Mon, 04 Jul 2011 09:50:19 +0000 Received: from plan9.cs.bell-labs.com ([172.31.204.68]) by plan9; Mon Jul 4 05:24:15 EDT 2011 Received: from leffe.cs.bell-labs.com ([172.31.133.236]) by plan9; Mon Jul 4 11:24:10 CES 2011 Date: Mon, 4 Jul 2011 11:24:20 +0200 From: Sape Mullender 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> X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [9fans] why not halt in x86 multicore X-BeenThere: 9fans@9fans.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> List-Id: Fans of the OS Plan 9 from Bell Labs <9fans.9fans.net> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: 9fans-bounces@9fans.net Errors-To: 9fans-bounces@9fans.net 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 --upas-ihhbvfktspkirdhouydzoffbwn--