Array
(
    [content] => 
    [params] => Array
        (
            [0] => /forum/threads/lisa-su-announces-ai-ryzen-chips-game-changer.17284/page-3
        )

    [addOns] => Array
        (
            [DL6/MLTP] => 13
            [Hampel/TimeZoneDebug] => 1000070
            [SV/ChangePostDate] => 2010200
            [SemiWiki/Newsletter] => 1000010
            [SemiWiki/WPMenu] => 1000010
            [SemiWiki/XPressExtend] => 1000010
            [ThemeHouse/XLink] => 1000970
            [ThemeHouse/XPress] => 1010570
            [XF] => 2021770
            [XFI] => 1050270
        )

    [wordpress] => /var/www/html
)

Lisa Su announces AI Ryzen Chips, Game Changer?

Each CPU port to the switch in such a system is in effect its own physical address space, including secure IDs in the high order bits and PIDs elsewhere in the packet. Other CPUs do not trust them and the managed switch has effectively a huge virtual mapping problem to sort out what is allowed to see what and how to transform the address on the way through the switch. You might be able to build a supercomputer with a single humongous client based on naive physical addresses, but that is not how clouds are built. They are built for paranoid, isolated clients. It is a big, complex problem already for 2-socket 128-core servers. It will be awesomely challenging at rack level.

And no, this is not off topic on a "game changer" thread. Both AMD and Intel are deeply aware of this and working on their own solutions. The game has barely started.
CXL.memory deals with physical memory, not virtual memory, akin to the memory controllers on CPUs. Protection mechanisms like rings and segmentation are CPU mechanisms, not those of memory controllers. Are the PIDs you're referring to Process Identifiers? Those are OS assigned; memory controllers do not have visibility into virtual memory field definitions. Physical memory management include operations like interleaving. CXL also includes peer-to-peer device memory access without host interaction. CXL.memory does track and enforce host and device ownership, but, again, that's physical memory, not virtual memory.
 
You are not thinking through how complex this becomes with thousands of cores and hundreds of customers in a rack. Every customer needs a separate logical space. Every CPU comes in on a separate port. What you see as a physical address is just a convention, which the switch will manipulate along with port and PID and upper address bits to construct mappings to the subset of resources you actually have access to. This map is not constant because VMs and containers come and go, and resources are allocated and released. The switch becomes a crucial leverage point for managing resources - a form of virtualization.

If CXL expects to scale to racks never mind data centers this is the level of functionality required. The switch will be a key part of the cloud fabric. This is just the CXL equivalent to what happened to IP switching.
 
You are not thinking through how complex this becomes with thousands of cores and hundreds of customers in a rack. Every customer needs a separate logical space. Every CPU comes in on a separate port. What you see as a physical address is just a convention, which the switch will manipulate along with port and PID and upper address bits to construct mappings to the subset of resources you actually have access to. This map is not constant because VMs and containers come and go, and resources are allocated and released. The switch becomes a crucial leverage point for managing resources - a form of virtualization.

If CXL expects to scale to racks never mind data centers this is the level of functionality required. The switch will be a key part of the cloud fabric. This is just the CXL equivalent to what happened to IP switching.
That isn't how CXL works or how memory controllers work. Download the 3.0 spec and read it for yourself. (It's only 911 pages. Light reading.) It looks like you also need a primer on computer architecture.


 
I was briefed on CXL before it was public, contributed guidance to its creators (still friends of mine) especially on .mem, isolation and security issues, since I was already working on disaggregated memory using CCIXX and CXL needed to catch up. I've kept up on the specs. Some of the diagrams used in CXL presentations on disaggregated memory were originally authored by me.

I have practical experience architecting servers, racks, and various subsystems which now count millions of machines. I've read every edition of CA:AQA and many others besides. You might want to reread my description of what really happens, again and think about how CPUs and individual busses are just components of a bigger system needed to build a modern cloud. Standards get virtualized, that is how large multiuser systems are built.

Over and out, thanks.
 
I was briefed on CXL before it was public, contributed guidance to its creators (still friends of mine) especially on .mem, isolation and security issues, since I was already working on disaggregated memory using CCIXX and CXL needed to catch up. I've kept up on the specs. Some of the diagrams used in CXL presentations on disaggregated memory were originally authored by me.

I have practical experience architecting servers, racks, and various subsystems which now count millions of machines. I've read every edition of CA:AQA and many others besides. You might want to reread my description of what really happens, again and think about how CPUs and individual busses are just components of a bigger system needed to build a modern cloud. Standards get virtualized, that is how large multiuser systems are built.

Over and out, thanks.
You're familiar with the CXL 3.0 specification and you've read all six or seven editions of the Hennessy/Patterson book? Perhaps you could explain the isolation and security features that are in the 3.0 spec?

By the way, I'm sure it's just a typo, but it's CCIX, not CCIXX.
 
Back
Top