|
|
Subscribe / Log in / New account

Kernel Summit: Processor panel

This article is part of LWN's 2004 Kernel Summit coverage.
Recent tradition states that the summit begins with presentations by processor manufacturers, who discuss their current plans with as much detail as is allowed before a group which refuses to sign nondisclosure agreements ahead of time. This year was no different, except that the presenters were more cautious about keeping the marketing content to a minimum.

Intel's Frank Binns discussed the future of the x86 and ia64 architectures. He touched on themes which would be repeated later: all of the processor manufacturers are headed toward putting multiple cores onto their chips, supporting virtualization, and improving their power management capabilities. Intel is also making a big deal about its "trusted computing" features - digital rights management stuff, in other words; if the other manufacturers are doing similar things, they knew better than to bring it up here.

One question for Intel was: will they be adding an I/O memory management unit to their AMD-compatible 64-bit chips? No such addition seems to be in the works; it's not clear they really even understand why an IOMMU is important. With luck, today's discussion will help to get the point across.

AMD's Rich Brunner also talked about dual core technology. He pointed out that, when two processors share a chip, they also share access to the memory controller. AMD figures that there will be contention between the processors about 10% of the time, meaning that two processors on the same chip will not perform as well as two entirely separate CPUs - a not entirely surprising result. The AMD talk also dedicated a lot of time to obscure extensions to the CPUID command aimed at improving license management for proprietary applications - a topic which was not of great interest here.

Bilaram Sinharoy discussed IBM's Power5 architecture. Multiple cores are not new for this architecture; current work is aimed at things like cramming more cache memory onto the chip. The Power5 hyperthreading model has been extended to allow different thread priorities in the hardware; with this mechanism, a process which is, for example, waiting for a spinlock can lower its priority and get out of the way while other things get done.

>> Next: Virtual Memory.


to post comments

Kernel Summit: Processor panel

Posted Jul 22, 2004 3:46 UTC (Thu) by jsbarnes (guest, #4096) [Link] (1 responses)

I'd like the term 'digital content control technology' to replace
'digital rights management' in the common vernacular, since it's more
accurate and arguably less loaded. And before you say so, yes I'm
probably living in a dream world.

Jesse

DRM TLA

Posted Jul 22, 2004 18:57 UTC (Thu) by Max.Hyre (subscriber, #1054) [Link]

rms has a good take on the subject. In plain English, DRM means Digital Restrictions Management: a much more honest way of describing the situation.

Kernel Summit: Processor panel

Posted Jul 22, 2004 19:12 UTC (Thu) by jzbiciak (guest, #5246) [Link]

On the dual-core processor issue: It's kinda interesting, actually. Some operations potentially get faster, and some get slower.

Consider variables shared across CPUs, such as locks and kernel data structures. As long as the chip is smart enough to forward snoops among the CPUs and not send the data out on the pins, the performance of cache line "ping pong" could go up (cycle count go down).

On a separate note, I wonder if any CPU vendors are considering an on-chip L3 that would be shared among the multiple cores? This could reduce some of the contention issues, depending on how you do it. You'd still have contention for L3, but L3 hits would be serviced much more quickly than accesses off-chip. Thus, the /length/ of the contention is less. Furthermore, there are tricks you can pull to reduce the amount of time you're contended, such as banking your memory aggressively.


Copyright © 2004, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds