Red Hat DLM

Oprofiling GFS showed that the gfs module caused dlm to spend around 60% in __find_lock_by_id. The question is why and is that a problem. So let's see what I'll find.

dlm_recvd small picture

How does dlm_recvd work?

Profile data with different table sizes

Results and oprofile output of comoonics-benchmark with different table sizes

Influence of Locktable sizes (rsbtbl_size/lkbtbl_size)

It might be that the size of the locktable and its dependencies influences the performance of find_lock_by_id.

changing scheduler priority of the dlm kernel processes

Another Idea is to increase the priority of the process(kernel) that calls the find_lock_by_id function

find_lock_by_id ideas

What does __find_lock_by_id and how is it called.

Oprofile Analysis

What did oprofile of a running system showed. And how was it influenced.