Needless flush list mutex reacquisitions in adaptive flushing

Bug #1117067 reported by Laurynas Biveinis on 2013-02-06
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
Medium
Laurynas Biveinis
5.1
Fix Released
Medium
Laurynas Biveinis
5.5
Fix Released
Medium
Laurynas Biveinis

Bug Description

Introduced by bug 1083058 fix, credit to Sergei.

One of adaptive flushing bits in srv_master_thread() reads

     mutex_exit(&flush_list_mutex);

     flushed_blocks_num = new_blocks_num + prev_flush_info.count
        - blocks_num;
     if (flushed_blocks_num < 0) {
      flushed_blocks_num = 0;
     }

     mutex_enter(&flush_list_mutex);
     bpage = UT_LIST_GET_FIRST(buf_pool->flush_list);

     prev_flush_info.count = UT_LIST_GET_LEN(buf_pool->flush_list);
     if (bpage) {
      prev_flush_info.space = bpage->space;
      prev_flush_info.offset = bpage->offset;
      prev_flush_info.oldest_modification = bpage->oldest_modification;
      mutex_exit(&flush_list_mutex);
     } else {
      mutex_exit(&flush_list_mutex);
      prev_flush_info.space = 0;
      prev_flush_info.offset = 0;
      prev_flush_info.oldest_modification = 0;
     }

It makes no sense to release the flush list mutex for such a short duration and then reacquire it for very short duration again.

Related branches

tags: added: xtradb
tags: added: low-hanging-fruit

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1311

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers