New device type: kDLCPUShared

[jermainewang]

Similar to kDLCPUPinned, CPU shared memory is allocated and managed quite differently from normal CPU memory. In DGL, we use shared memory to store large graphs so it is quite common to see operation to copy data between CPU memory and shared memory. I guess we could also use the extension type to handle that, but want to bring up this issue to see whether it is better to have a type for that in DLPack.

cc @zheng-da

[tqchen]

Can you elaborate what exactly CPU shared is? Is it a DRAM region? Any special support from OS?

[szha]

I think this is referring for example /dev/shm on linux? It's often used in dataloader and multiprocessing for data pipelines

[jermainewang]

The "shared memory" referred here is a RAM region created by one process that can be accessed by other processes. It is mainly used for inter-process communication or a shared data buffer .

One such scenario is on NUMA machine, we want to launch one process for each NUMA core. The processes might share some common data (in our case, a graph structure), so we put it in shared memory.

OS does have special support for shared memory. The most commonly used is the POSIX shared memory APIs: shm_open for create (or open an existing) shared memory buffer, shm_unlink to delete the buffer and so on. Also mmap can map files into memory so a file can also serve as a buffer.

[jermainewang]

Ping to re-active this discussion. It it's hard to add another enum type, I wonder what's the best workaround? For shared memory, I could see two concerns.

• Each shared memory region has a string name which is given when it is created. However, in current DLPack, the device id is only an integer. The problem could be solved by maintaining a singleton mapping from string name to an integer id outside of DLPack.
• Shared memory has two different kinds of allocation/deallocation: create and open. Create initializes a new region while open just loads a created region. Again, I feel this could also be handled outside of DLPack.

Thus, I could see two technical routes:

1. Reuse kDLCPU enum and use device_id for the shared memory name.
2. Put kDLCPUShared as an extension type. I don't know exactly how this could be done but I do see a kDLExtDev enum.

[link89]

Is there any working example of /dev/shm support now? I am thinking of using dlpack to implement some high performance IPC solution for a program that need to exchange data between a C++ process and a Python process.