Optimize Commit pipeline performance

[ethercflow]

Follow up on #267

Optimize the waiting delay caused by the uneven load of the writer wb: the writer who enters the request queue later enters the commit phase first.

Signed-off-by: Wenbo Zhang ethercflow@gmail.com

[ethercflow]

@Connor1996 @tabokie PTAL, thanks!

[tabokie]

Please add some descriptions for the new algorithm. I didn't find any on the weekly report.

[ethercflow]

Please add some descriptions for the new algorithm. I didn't find any on the weekly report.

1. Create a task queue for each writer, the difference with MultiWriteBatch is that the latter shares the queue；
2. After each writer confirms the order of submission in the request queue, it loops through its own task queue. The definition of each task is the same as that of MultiWriteBatch；
3. If the head of the request queue completes the memtable write operation first and enters the commit stage, it can return directly without waiting for other writers. This behavior is consistent with the previous pipelined commit；
4. If the non-head writers first enter the commit phase and find that the task queue of the head writer has pending tasks, the loop will take out tasks from the task queue of the head writer for execution；
   4.1 After the header is completed, it is found that the helpers are also completed, then pop these writers from the request queue in turn, and notify the helpers to return；
   4.2 If the header completes, but finds that the tasks the helpers performed for him have not yet been processed, wait for the helpers to complete and wake it up to clean up from the request queue.

Sorry I missed the email, I've add the descriptions. Please let me know if it's clear enough, thanks! @tabokie @Connor1996

[ethercflow]

Hi @tabokie @Connor1996 I've updated a version according to your suggestions (except for the supplementary comments, which will be added later), PTAL again, thank you.

[ethercflow]

I have a few questions about how to deal with memtable write error:

1. What will happen if write WAL successfully, but write memtable failed?
2. We loop write memtable, according to the current logic, only the latest error is recorded, it this expected?
3. The current helper thread does not call WriteStatusCheck(writer.status); after helping to execute wb, is this ok? (This function is a protected member defined in class db_impl, which is more troublesome to call in write_thread.cc)

[tabokie]

1. Do nothing and return the error. RocksDB will ignore the error when replaying logs during recovery (if paranoid_checks is not set).
2. I don't think it's a big issue. Memtable don't err unless user writes are seriously malformed.
3. Could you run the check after commit? at which point all tasks should be completed.

[ethercflow]

1. Do nothing and return the error. RocksDB will ignore the error when replaying logs during recovery (if paranoid_checks is not set).
2. I don't think it's a big issue. Memtable don't err unless user writes are seriously malformed.

Got it, thanks!

3. Could you run the check after commit? at which point all tasks should be completed.

I think it's OK.

[tabokie]

I suggest adding another atomic flag persisted to mark that a request is safe to be applied. It can solve the two issues in my comments.

[Connor1996]

rest LGTM

[tabokie]

Might need to cherry-pick to 6.29.tikv branch.

[ethercflow]

/run-test