kvs: have two request handlers for commits & fences #1349
Conversation
In relaycommit_request_cb(), fix corner case in which errno was not set correctly in error path.
In order to differentiate commits from fences better, create a new set of request callbacks kvs.fence and kvs.relayfence. In libkvs, have commits call kvs.commit and have fences call kvs.fence appropriately.
As nprocs is always 1 with commits, remove it from commit RPCs. Adjust callers in libkvs appropriately.
Commit requests are each unique, therefore there is no need to lookup if a commit already exists. In addition, there is no need to check that flags & nprocs are identical to prior calls.
|
Hmmm, saw a and also hit #1025. Restarted builders. |
|
Diff coverage doesn't look to good (63.82%) but looking through the coverage, its predominantly "impossible" error path coverage being missed. Not sure I'll be able to eek out better coverage with unit tests. |
|
Good cleanup! I'd probably drop the commit that diverts fence to commit if fence nprocs=1, since that left turn isn't likely justified by any real world benefit. In the commit request callback, it looks like a uuid is still being created, but on the server side. Is that necessary? If it is, it might actually be better to do it on the client side to distribute the workload rather than concentrating it on the leader rank. Slightly unrelated to this PR, but the duplication of the rpc call in the client (my fault) looks to be just to avoid creating an empty ops array? I'm not sure that works out to be helpful, since jansson probably just creates it internally from |
Yeah. It's b/c there is shared code for commits & fences returning success/error codes to the original callers. I need a name to attach to an RPC message for later lookup. This is all in the
That sounds like a good idea.
Yup.
Are you suggesting we create an empty ops array if the user passes in txn == NULL? I suppose that would clean it up a bit overall. |
I was, but now that you mention it, why not require txn != NULL? If the user wants to commit/fence an empty transaction, requiring them to create it doesn't seem unreasonable... |
Sounds good, although I'll leave that to a different PR. I'll make an issue. |
In internal function of kvstxn, refactor kvstxn_create() to take parameters instead of a treq_t.
In kvstxn_mgr_process_transaction_request(), do not check/set processing flag and do not check if transaction count has reached nprocs. Make that something the caller is required to do. This separates treq logic out of the kvstxn API far more. Adjust core KVS file appropriately. Most notably, in fences calls to treq_count_reached() must be checked, but in commits they do not.
Refactor kvstxn_mgr_process_transaction_request() into kvstxn_mgr_add_transaction(). The new function takes direct parameters needed for a ready transaction (i.e. name, ops, flags). With this refactoring, treq_t transactions are now completely decoupled from the kvstxn_t API. So remove now unnecessary header includes and object linking.
In relaycommit_request_cb(), do not create a treq data structure. As commits are individually unique, it is not necessary. Instead, pass ops, name, and flags to kvstxn_mgr_add_transaction() directly. In commit_request_cb(), ops do not need to be stored as commits are unique.
|
Just re-pushed with recommended changes. To my surprise, no conflicts when deleting the two patches implementing the issues listed above. |
|
hit #1311, restart builder |
Codecov Report
@@ Coverage Diff @@
## master #1349 +/- ##
==========================================
- Coverage 78.55% 78.51% -0.04%
==========================================
Files 162 162
Lines 29619 29686 +67
==========================================
+ Hits 23266 23307 +41
- Misses 6353 6379 +26
|
|
Merging. Thanks! |
Instead of sending all commit and fence RPCs to the same kvs handler, have one for commits (
kvs.commit) and one for fences (kvs.fence).This makes the code far clearer on how commits and fences are different.
A) commits do not require "nprocs" and "name" to be sent in their RPCs, so they are now removed.
B) a nice chunk of code is not needed for commits b/c nprocs is always 1 (i.e. don't need to do a lookup), so all that code is now removed in the commit path.
This completes issue #1344.
I was curious if this would improve performance, as commits are now far simpler than fences (less allocations, etc.). A soak test showed:
before
after
Granted only 1 run over 1000 jobs, but mean is a tad better.