<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">Also, many LDLM locks do not have an interval. The node which has the most of them is generally an MDS, which can have millions in certain scenarios, and makes no use of the interval at all. This is a lot of lost memory
if we're really adding part of the interval_tree in to the lock struct (I haven't looked at the patch).</p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> lustre-devel <lustre-devel-bounces@lists.lustre.org> on behalf of NeilBrown <neilb@suse.com><br>
<b>Sent:</b> Wednesday, February 20, 2019 4:37:58 PM<br>
<b>To:</b> James Simmons; Lustre Developement<br>
<b>Cc:</b> Vitaly Fertman<br>
<b>Subject:</b> Re: [lustre-devel] Lustre interval tree problems</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">On Wed, Feb 20 2019, James Simmons wrote:<br>
<br>
> With the port of the interval tree work to the OpenSFS branch several <br>
> problems have been pointed out in the implementation which impacts<br>
> performance and the memory footprint in some cases.<br>
><br>
> The biggest issues is the ability to add duplicate locks. The reason<br>
> the original implementation avoided adding duplicate locks was to<br>
> avoid the extra compares being done with the same type of locks.<br>
> Especially in the case of the range lock where you can end up with<br>
> many duplicate read locks [0-EOF]. Comparing with 1000s of identical<br>
> read locks will have an impact. Their is teh question of the memory<br>
> foot print in this case as well. I believe this is the case with the<br>
> ldlm locks as well since the ability to skip large lock amounts if<br>
> not matching has been lost.<br>
><br>
> The next problem Vitaly pointed in the implementation is the emebedding<br>
> of lit_root in ldlm_interval_tree also has a negative impact. Since many<br>
> locaks are kept in memory he wants to see that ldlm_lock struct stay as<br>
> small as possible. Explained that is why ldlm_interval was not original<br>
> embedded but allocated separately. I added him to this chain.<br>
<br>
Thanks for this valuable feedback! I'll look over the code again with<br>
these issues in mind, and let you know what I find.<br>
<br>
NeilBrown<br>
</div>
</span></font></div>
</body>
</html>