The overall theme for this PR is to improve scalability by reducing the number of client requests that end up generating an RPC to a file owner. Mostly, this is done by identifying when many clients on a node are generating a request for the same information, and making sure the node's local server only sends a single remote request to get the information from the owner. Similarly, when making updates to a file (e.g., new extents), this adds some batching of the updates for a given node. In general, this reduces the number of requests that reach the owner from O(# clients) to O(# nodes).
This PR also includes some code cleanup (removing last vestiges of MPI and MDHIM from the server) and a few minor bug fixes.
Motivation and Context
At higher numbers of clients (above 2k) on Frontier, we were seeing client request timeouts due to the serialized processing of these requests at the owner server.
How Has This Been Tested?
With these changes, Unify examples with up to 8k clients (8 ppn @ 1k nodes, or 32 ppn @ 256 nodes) were passing more often. There is still more work to do on multithreading the service manager who processes the file owner requests.
Types of changes
[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[x] Performance enhancement (non-breaking change which improves efficiency)
[x] Code cleanup (non-breaking change which makes code smaller or more readable)
[ ] Breaking change (fix or feature that would cause existing functionality to change)
[ ] Testing (addition of new tests or update to current tests)
[ ] Documentation (a change to man pages or other documentation)
Checklist:
[x] My code follows the UnifyFS code style requirements.
Description
The overall theme for this PR is to improve scalability by reducing the number of client requests that end up generating an RPC to a file owner. Mostly, this is done by identifying when many clients on a node are generating a request for the same information, and making sure the node's local server only sends a single remote request to get the information from the owner. Similarly, when making updates to a file (e.g., new extents), this adds some batching of the updates for a given node. In general, this reduces the number of requests that reach the owner from O(# clients) to O(# nodes).
This PR also includes some code cleanup (removing last vestiges of MPI and MDHIM from the server) and a few minor bug fixes.
Motivation and Context
At higher numbers of clients (above 2k) on Frontier, we were seeing client request timeouts due to the serialized processing of these requests at the owner server.
How Has This Been Tested?
With these changes, Unify examples with up to 8k clients (8 ppn @ 1k nodes, or 32 ppn @ 256 nodes) were passing more often. There is still more work to do on multithreading the service manager who processes the file owner requests.
Types of changes
Checklist: