Implement IPC cache for umfOpenIPCHandle function

[vinser52]

Description

This PR adds initial set of changes to implement cache for opened IPC handles.
The new third-party data structure (uthash - has map implementation) is added. The same data structure is used by MPI to implement IPC cache. Here is the uthash documentation. Here is the original source repo

Fixes: #403

Checklist

• Code compiles without errors locally
• All tests pass locally
• CI workflows execute properly
• All newly added source files have a license
• All newly added source files are referenced in CMake files

[bratpiorka]

@lplewa or @ldorau please review

[ldorau]

Please enable lines no: 356 and 359:

unified-memory-framework/test/ipcFixtures.hpp

Lines 355 to 359 in cdc0310

	// TODO fix it - it does not work in case of IPC cache hit
	// EXPECT_EQ(stat.allocCount, stat.getCount);
	EXPECT_EQ(stat.getCount, stat.putCount);
	// TODO fix it - it does not work in case of IPC cache hit
	// EXPECT_EQ(stat.openCount, stat.getCount);

It seems that the check in the line no 356:

EXPECT_EQ(stat.allocCount, stat.getCount);

still fails in the umf-provider_devdax_memory test:

[ RUN      ] DevDaxProviderDifferentPoolsTest/umfIpcTest.AllocFreeAllocTest/2
/home/ldorau/work/unified-memory-framework/test/ipcFixtures.hpp:354: Failure
Expected equality of these values:
  stat.allocCount
    Which is: 5
  stat.getCount
    Which is: 1

[  FAILED  ] DevDaxProviderDifferentPoolsTest/umfIpcTest.AllocFreeAllocTest/2, where GetParam() = (0x7f3e254f5660, NULL, 0x7f3e254f5200, 0x55cdc299f760, 0x55cdc299f048, false) (0 ms)
...
[  FAILED  ] 1 test, listed below:
[  FAILED  ] DevDaxProviderDifferentPoolsTest/umfIpcTest.AllocFreeAllocTest/2, where GetParam() = (0x7f3e254f5660, NULL, 0x7f3e254f5200, 0x55cdc299f760, 0x55cdc299f048, false)

 1 FAILED TEST

[lplewa]

Please next time do not include half done features. Untested/unused features deceases code coverage, but also they can be detected by static analyze tools as an bugs - in short they might cause troubles after the merge. Also nothing is more permanent that temporary solution, but i trust you that it isn't a case here ;)

[vinser52]

Please enable lines no: 356 and 359:

unified-memory-framework/test/ipcFixtures.hpp

Lines 355 to 359 in cdc0310

	// TODO fix it - it does not work in case of IPC cache hit
	// EXPECT_EQ(stat.allocCount, stat.getCount);
	EXPECT_EQ(stat.getCount, stat.putCount);
	// TODO fix it - it does not work in case of IPC cache hit
	// EXPECT_EQ(stat.openCount, stat.getCount);

It seems that the check in the line no 356:

EXPECT_EQ(stat.allocCount, stat.getCount);

still fails in the umf-provider_devdax_memory test:

[ RUN      ] DevDaxProviderDifferentPoolsTest/umfIpcTest.AllocFreeAllocTest/2
/home/ldorau/work/unified-memory-framework/test/ipcFixtures.hpp:354: Failure
Expected equality of these values:
  stat.allocCount
    Which is: 5
  stat.getCount
    Which is: 1

[  FAILED  ] DevDaxProviderDifferentPoolsTest/umfIpcTest.AllocFreeAllocTest/2, where GetParam() = (0x7f3e254f5660, NULL, 0x7f3e254f5200, 0x55cdc299f760, 0x55cdc299f048, false) (0 ms)
...
[  FAILED  ] 1 test, listed below:
[  FAILED  ] DevDaxProviderDifferentPoolsTest/umfIpcTest.AllocFreeAllocTest/2, where GetParam() = (0x7f3e254f5660, NULL, 0x7f3e254f5200, 0x55cdc299f760, 0x55cdc299f048, false)

 1 FAILED TEST

Done. The issue was caused by the implementation of a scalable pool. When we do the first umfPoolMalloc the scalable pool internally does five 2MB allocations from the memory provider. So checking EXPECT_EQ(stat.allocCount, stat.getCount) does not make sense. I removed it, but EXPECT_EQ(stat.openCount, stat.getCount); should pass. I tested it with the OS provider and it works. I have no system with devdax, so let's see if CI passes.

[ldorau]

@vinser52 CI builds fail

[vinser52]

@vinser52 CI builds fail

Yeah, I saw that. I cannot reproduce it locally. My guess is that in case of CI there are some limits exceed with scalable pool because it uses 2MB slabs. So I can try to decrease memory pressure by decreasing number of allocations in corresponding test or disable test with scalable pool for now. I will investigate today.

[vinser52]

@ldorau I have moved the test with the scalable pool into a separate PR #860. Now this PR should pass CI validation.
I am going to introduce a config API for a scalable pool. It allows us to set the slab size to something less than 2MB and use such a config for the test.

[vinser52]

@bratpiorka I just rebased the branch because there was a conflict with main. After CI is passed we can merge.