[Ocfs2-devel] [PATCH 1/5] ocfs2/dlm: dynamically allocate lvb for dlm_lock_resource
Sunil Mushran
sunil.mushran at oracle.com
Tue Sep 14 10:02:34 PDT 2010
===== 2010-09-13 : 20:25 UUID:4D5296E659E349F0997FA8997E007D8E =====
85733 M
45077 N
85714 O
1 P
2 Q
1 S
2249 W
1 Y
I guess the feature will be useful considering the number of lockres'
with lvb is less than half. Sometimes a third. So significant savings.
Having said that, it should be noted that the test itself is a bit biased
as a kernel build will have more than normal number of open/dentry
locks.
Still, I would vote for the savings.
Wengang,
BTW, we are already passing the lvb flag. Grep on DLM_LKF_VALBLK
and LKM_VALBLK. Much better if we key on that rather than the lock
name.
Sunil
On 09/13/2010 08:48 PM, MARCOS MATSUNAGA wrote:
> Sunil,
>
> I ran buildkernel and collect some of the stats that you requested.
>
> You can find them at http://oss.oracle.com/~mmatsuna/ocfs2-stats/ and
> the files are:
> ocfs2-stat-6850.log
> <http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-6850.log>
> ocfs2-stat-6942.log <http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-6942.log>
> ocfs2-stat-10059.log <http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-10059.log>
> ocfs2-stat-32460.log <http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-32460.log>
>
> I collected samples every 30 seconds on all nodes. Each node starts
> two builds in parallel and the make command is "make -j2 V=1".
>
> On 9/13/2010 1:54 PM, Sunil Mushran wrote:
>> On 08/26/2010 06:06 AM, Wengang Wang wrote:
>>
>>> This patch tries to dynamically allocate lvb for dlm_lock_resource which needs to access lvb.
>>>
>>> Without the patch applied,
>>> [wwg at cool linux-2.6]$ egrep "o2dlm_lockres" /proc/slabinfo
>>> o2dlm_lockres 42 42 256 32 2 : tunables 0 0 0 : slabdata 2 2 0
>>>
>>> After patch applied,
>>> [wwg at cool linux-2.6]$ egrep "o2dlm_lockres" /proc/slabinfo
>>> o2dlm_lockres 42 42 192 21 1 : tunables 0 0 0 : slabdata 2 2 0
>>>
>>> #the result is taken on i686
>>>
>>>
>> So the core logic allocates a lvb or not based on the lock name. That
>> will not work because we support userdlm (not to be confused with
>> userspace stack that uses fsdlm) that allows the user to specify the name.
>>
>> A better solution is to make the user pass in a flag to create the lvb.
>> That's one issue.
>>
>> The other issue concerns the real savings. While the savings on a per
>> lockres basis are impressive (will be even more on a 64-bit system), I
>> am unsure on the overall savings.
>>
>> To check that, run some workload... like a kernel build (one node should
>> be sufficient) and gather some numbers below.
>>
>> # cd /sys/kernel/debug/o2dlm/<domain>
>> # grep -h "^NAME:" locking_state | sort | cut -c6 | uniq -c
>>
>> Marcos, Can you also gather this stat when you run metadata heavy
>> tests.
>>
>> Thanks
>> Sunil
>>
>> _______________________________________________
>> Ocfs2-devel mailing list
>> Ocfs2-devel at oss.oracle.com
>> http://oss.oracle.com/mailman/listinfo/ocfs2-devel
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.oracle.com/pipermail/ocfs2-devel/attachments/20100914/1763125a/attachment.html
More information about the Ocfs2-devel
mailing list