Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extend the IPC cache of get/put operations to support evictions and size threshold #1003

Open
vinser52 opened this issue Dec 17, 2024 · 0 comments
Assignees
Labels
enhancement New feature or request

Comments

@vinser52
Copy link
Contributor

Rationale

Today we have two IPC caches in UMF:

  1. For the "producer" flow when an IPC handle is created by calling the umfGetIPCHandle function and released by calling the umfPutIPCHandle function.
  2. For the "consumer" flow when an IPC handle is opened (usually by another process) by calling the umfOpenIPCHandle and closed by calling the umfCloseIPCHandle function.

This issue is related to the "producer" flow. Today it uses just the critnib map to cache created IPC handles from memory provider. BUt we need to support the threshold for the cache size as we do for the opened IPC handles cache in #998.

Description

Introduce the UMF_MAX_CREATED_IPC_HANDLES environment variable (the name is subject to discussion) to limit the cache size. As for the consumer flow use true cache implementation (hash amp + LRU list) instead of just a map.

API Changes

No API changes. Only a new environment variable to control the maximum cache size

Implementation details

See the ipc_cache.h and the ipc_cache.c for how IPC cache is implemented for the "consumer" flow. We need almost the same for the "producer" flow. Only the cache key and value structures will be different.

Meta

@vinser52 vinser52 added the enhancement New feature or request label Dec 17, 2024
@vinser52 vinser52 self-assigned this Dec 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant