[MDEV-28369] ibuf_bitmap_mutex is an unnecessary contention point Created: 2022-04-20  Updated: 2022-04-21  Resolved: 2022-04-21

Status: Closed
Project: MariaDB Server
Component/s: Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4, 10.5, 10.6, 10.7, 10.8, 10.9
Fix Version/s: 10.3.35, 10.4.25, 10.5.16, 10.6.8, 10.7.4, 10.8.3, 10.9.1

Type: Bug Priority: Major
Reporter: Marko Mäkelä Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: performance


 Description   

The only purpose of ibuf_bitmap_mutex is to prevent a deadlock between two concurrent invocations of ibuf_update_free_bits_for_two_pages_low(a,b,mtr1) and ibuf_update_free_bits_for_two_pages_low(b,a,mtr2). The mutex is unnecessarily serializing the execution of the function. To avoid deadlocks, the following should suffice:

  /* Avoid a deadlock by acquiring multiple bitmap page latches in
 
  a consistent order (smaller page identifier first). */
 
  if (block1->page.id() > block2->page.id())
 
    std::swap(block1, block2);
 
 
 
  ibuf_set_free_bits_low(block1, ibuf_index_page_calc_free(block1), mtr);
 
  ibuf_set_free_bits_low(block2, ibuf_index_page_calc_free(block2), mtr);



 Comments   
Comment by Marko Mäkelä [ 2022-04-21 ]

It occurred to me that we can compare the pointers directly. What matters is that every code path that could acquire and hold multiple change buffer bitmap page latches will acquire them in a deterministic order.

  if (block1 > block2)
 
    std::swap(block1, block2);

I think that most of the time we would have block1 == block2. Exclusive page latches can be acquired recursively.

Comment by Matthias Leich [ 2022-04-21 ]

origin/bb-10.6-MDEV-28369 2d436f3541c5acb8f5808436f7913e80f2937f1f 2022-04-20T14:16:46+03:00
performed well in RQG testing.

Generated at Thu Feb 08 10:00:12 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.