Needless flush list mutex reacquisitions in adaptive flushing

Bug #1117067 reported by Laurynas Biveinis on 2013-02-06
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to
Fix Released
Laurynas Biveinis
Fix Released
Laurynas Biveinis
Fix Released
Laurynas Biveinis

Bug Description

Introduced by bug 1083058 fix, credit to Sergei.

One of adaptive flushing bits in srv_master_thread() reads


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

     bpage = UT_LIST_GET_FIRST(buf_pool->flush_list);

     prev_flush_info.count = UT_LIST_GET_LEN(buf_pool->flush_list);
     if (bpage) { = bpage->space;
      prev_flush_info.offset = bpage->offset;
      prev_flush_info.oldest_modification = bpage->oldest_modification;
     } else {
      mutex_exit(&flush_list_mutex); = 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:

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

Other bug subscribers