From mboxrd@z Thu Jan 1 00:00:00 1970 Message-Id: <2B1E6A61-A1BB-4039-BECD-E02FC4C75B11@telus.net> From: Paul Lalonde To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <20080715080153.1B5B25B50@mail.bitblocks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v926) Date: Tue, 15 Jul 2008 10:50:46 -0700 References: <20080715080153.1B5B25B50@mail.bitblocks.com> Subject: Re: [9fans] Plan 9 and multicores/parallelism/concurrency? Topicbox-Message-UUID: e73b0ec0-ead3-11e9-9d60-3106f5b1d025 On 15-Jul-08, at 1:01 AM, Bakul Shah wrote: > > I suspect a lot of this complexity will end up being dropped > when you don't have to worry about efficiently using the last > N% of cpu cycles. Would that I weren't working on a multi-core graphics part... That N% is what the game is all about. > When your bottleneck is memory bandwidth > using core 100% is not going to happen in general. But in most cases, that memory movement has to share the bus with increasingly remote cache accesses, which in turn take bandwidth. Affinity is a serious win for reducing on-chip bandwidth usage in cache-coherent many-core systems. > And I am > not sure thread placement belongs in the kernel. Why not let > an application manage its allocation of h/w thread x cycle > resources? I am not even sure a full kernel belongs on every > core. I'm still looking for the right scheduler, in kernel or user space, that lets me deal with affinitizing 3 resources that run at different granularities: per-core cache, hardware-thread-to-core, and cross-chip caches. There's a rough hierarchy implied by these three resources, and perfect scheduling might be possible in a purely cooperative world, but reality imposes pre-emption and resource virtualization. > Unlike you I think the kernel should do even less as more and > more cores are added. It should basically stay out of the > way. Less government, more privatization :-) So may be > the plan9 kernel would a better starting point than a Unix > kernel. Agreed, less and less in the kernel, but *enough*. I like resource virtualization, and as long as it gets affinity right, I win. Paul