<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<pre>===== 2010-09-13 : 20:25 UUID:4D5296E659E349F0997FA8997E007D8E =====
85733 M
45077 N
85714 O
1 P
2 Q
1 S
2249 W
1 Y
</pre>
<br>
I guess the feature will be useful considering the number of lockres'<br>
with lvb is less than half. Sometimes a third. So significant savings.<br>
<br>
Having said that, it should be noted that the test itself is a bit
biased<br>
as a kernel build will have more than normal number of open/dentry<br>
locks.<br>
<br>
Still, I would vote for the savings.<br>
<br>
Wengang,<br>
BTW, we are already passing the lvb flag. Grep on DLM_LKF_VALBLK<br>
and LKM_VALBLK. Much better if we key on that rather than the lock<br>
name.<br>
<br>
Sunil<br>
<br>
On 09/13/2010 08:48 PM, MARCOS MATSUNAGA wrote:
<blockquote cite="mid:4C8EF09B.2000100@oracle.com" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<tt>Sunil,<br>
<br>
I ran buildkernel and collect some of the stats that you requested.<br>
<br>
You can find them at <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/">http://oss.oracle.com/~mmatsuna/ocfs2-stats/</a>
and the files are:</tt><br>
<a moz-do-not-send="true"
href="http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-6850.log"><tt>ocfs2-stat-6850.log</tt></a><tt><br>
</tt>
<pre><tt><a moz-do-not-send="true"
href="http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-6942.log">ocfs2-stat-6942.log</a>
<a moz-do-not-send="true"
href="http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-10059.log">ocfs2-stat-10059.log</a>
<a moz-do-not-send="true"
href="http://oss.oracle.com/%7Emmatsuna/ocfs2-stats/ocfs2-stat-32460.log">ocfs2-stat-32460.log</a></tt></pre>
<br>
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".<br>
<br>
On 9/13/2010 1:54 PM, Sunil Mushran wrote:
<blockquote cite="mid:4C8E654F.4050503@oracle.com" type="cite">
<pre wrap="">On 08/26/2010 06:06 AM, Wengang Wang wrote:
</pre>
<blockquote type="cite">
<pre wrap="">This patch tries to dynamically allocate lvb for dlm_lock_resource which needs to access lvb.
Without the patch applied,
[wwg@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@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
</pre>
</blockquote>
<pre wrap="">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
<a moz-do-not-send="true" class="moz-txt-link-abbreviated"
href="mailto:Ocfs2-devel@oss.oracle.com">Ocfs2-devel@oss.oracle.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://oss.oracle.com/mailman/listinfo/ocfs2-devel">http://oss.oracle.com/mailman/listinfo/ocfs2-devel</a>
</pre>
</blockquote>
</blockquote>
<br>
</body>
</html>