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. As was answered on the GFS Mailinglist:
Thanks for doing this, it's very interesting. For the dlm search_hashchain, could you try changing rsbtbl_size to 1024 (the default is 256). echo 1024 > /proc/.../rsbtbl_size after loading the dlm module, but before the lockspace is created. For gfs, I haven't looked very closely, but the linked list could probably be simply turned into a hash table. We'd want to study it more closely to make sure that the long non-hashed list is really the right thing to fix (i.e. we don't want to just fix a symptom of something else). Dave
So it seems that the lists are getting to big whereas there should be more buckets. As locks are seperated in buckets and lists.
LKB lkid's are 32 bits and have two 16 bit parts. The bottom 16 bits are a random number between 0 and lockidtbl_size-1. This random number specifies the "bucket" for the lkb in lockidtbl. The upper 16 bits are a sequentially assigned per-bucket id.
Because the 16 bit id's per bucket can roll over, a new lkid must be checked against the lkid of all lkb's in the bucket to avoid duplication.
The function find_lock_by_id walks through this array of lists.
As far as I understand it the rsb is a mapping from locks to resources referenced by names. The name itself correlates to the random number for the bucket in the locktable. Every element of this rsb array holds a list of rsbs. So both rsb and lkts are arrays of lists.
The function search_hashchain walk through this array of lists.
So why not change sizes of both lists synchronous.
Locking into lockspace.c/new_lockspace the rsbtbl_size is the size of a resource block table so it seems.
size = dlm_config.rsbtbl_size; ls->ls_rsbtbl_size = size; ls->ls_rsbtbl = kmalloc(sizeof(struct dlm_rsbtable) * size, GFP_KERNEL);
Whereas the lkstbl_size seems to be the size of the buckets (array) where the lists are held. In my opinion increasing this size should increase the size of the buckets being available and therefor perhaps decrease the size of the list?!