From: Marc Alff
Date: September 8 2010 7:04pm
Subject: Re: bzr commit into mysql-5.5-bugfixing branch (marc.alff:3203) Bug#56528
List-Archive: http://lists.mysql.com/commits/117792
Message-Id: <4C87DE53.1070803@oracle.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Hi Vlad

On 9/8/10 12:51 PM, Vladislav Vaintroub wrote:
> Marc, just an idea.. With the big group of mutexes or rwocks, each having the same code and lock paths (like it is the case of
> Innodb mutexes and rwlocks). The user would not care of each of them individually, for  someone analyzing performance it is just one
> "page protection lock", he would not think about page protection lock for page 1578.  So maybe it just makes sense to use the same
> PFS key for the whole group, rather than single key  per every single item ?
>

The PFS key is the same already.

What is per mutex instance is the instrumentation of the mutex itself, 
which costs 136 bytes per instance.
Look for the entry named MUTEX_INSTANCE.ROW_SIZE in the output of SHOW 
ENGINE PERFORMANCE_SCHEMA STATUS.

Attempting to share this memory can only leads to bottlenecks and 
performance degradations, since the performance schema implementation 
can no longer be lock free, and protected by the mutex itself.

I look at it this way: if code in the server actually made an effort to 
have 1 mutex per "page" or record in general, this is because 1 global 
mutex for every record does not scale.
In this case, the performance schema using a single lock with a single 
memory buffer to keep stats of all the mutexes of the same class would 
just destroy all efforts made in the code to scale, and re introduce the 
same problem just one layer below.

Regards,
-- Marc