MySQL Bugs: #69232: buf_dblwr->mutex can be splited into two

Bug #69232	buf_dblwr->mutex can be splited into two
Submitted:	14 May 2013 16:48	Modified:	23 Sep 2017 15:37
Reporter:	zhai weixiang (OCA)	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S4 (Feature request)
Version:	5.7	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
Recently I am trying to understand the code path related to the  double write buffer.

In MySQL 5.6, the double write buffer  was divided into two parts, one for batch flush(0~119) , and the other for single page flush(120~127).

if the flush type is BUF_FLUSH_SINGLE_PAGE, then function buf_dblwr_write_single_page was called . 

In buf_dblwr_write_single_page,  buf_dblwr->mutex was only used to protect the variables bellow:

buf_dblwr->s_reserved
buf_dblwr->in_use[i]  ,   i>=120
buf_dblwr->buf_block_arr[i]  , i>=120

these variables were only used by  single page flushes.

And in other functions (buf_dblwr_update, buf_dblwr_flush_buffered_writes, buf_dblwr_add_to_batch),   buf_dblwr->mutex was only used to protect the variables that only related to batch flush.

So I think buf_dblwr->mutex can be splited into two , one is used to protect the batch flush ,and the other is used to protect the single page flush.

I have written a rough patch but  frustratingly  I haven't see notcieable improvement of performance (IO-bound workload, small buffer pool ).

I don't know if my idea is reasonable, and that's why I filed this bug.

How to repeat:
read the related code 

Suggested fix:
I don't know...

a rough patch

Attachment: patch.diff (application/octet-stream, text), 4.84 KiB.

For typical write workload, single flush type is almost 0, therefore, it might be not meaningful for the mutex splitting.

Hi!

First of all, we can not have feature requests for 5.6, but only 5.7 and higher. But, more important ...

Since both buffers use the same file for double writing, a single mutex makes more sense.

Do you agree ???

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".