https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-13134 Lustre <p>Currently we use kmalloc for cl_page allocation, this is because<br/> cl_page size could be different with different objects(normal clio, obdecho objects)</p> <p>for most of cases we have 400+ bytes cl_page, kmalloc use 512 bytes slab behind, so instead of doing this behind, We just try to use private slab pool directly(512 bytes).</p> <p>This make much sesne especially for Direct IO since it try to allocate/free cl_page very frequently.</p> LU-13134

try to use slab allocation for cl_page

Improvement Minor Resolved Fixed Wang Shilong Wang Shilong Tue, 14 Jan 2020 13:57:42 +0000 Wed, 26 May 2021 21:34:34 +0000 Sat, 4 Jul 2020 04:59:15 +0000 Lustre 2.14.0 0 9 <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/37225" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37225</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: use slab allocation for cl_page<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: c6166bacea2609c0deb83577470334ce5a969a69</p> <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/37227" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37227</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: use slab allocation for cl_dio_aio<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: f9ec3996c6a94286f7581e41932ae1367ca6075e</p> <p>These patches seem reasonable, but do we have any benchmarks showing improvement or perf data showing contention/time lost in these areas?</p> <p>Hi Patrick,</p> <p>Not yet, i am looking some benchmark numbers from Ihara, the motivation of this is when we did fio(DIO) benchmark using GPUDirect integrated with Lustre, we saw 10% overhead from cl page allocation/free.</p> <p>I think this patch is a good start, but I'm wondering if there is something more dramatic that we can do to reduce the size of cl_page (in a separate patch)? If you consider that we are allocating a whopping 408 bytes per 4096-byte page, that is still 10% of ALL of the size of the Lustre cached data. While it is down from previously 512 bytes per 4096-byte page (12%), there is definitely more that could be done. While I'm not an expert with CLIO, it seems like a <b>lot</b> of complexity in this code that could be removed, and although the flexibility of abstraction in <tt>cl_page</tt> is interesting, it definitely has a lot of overhead.</p> <p>For example, since we already have fixed-size cl_page allocations, do we really need <tt>cpl_linkage</tt> linked list in <tt>cl_page_slice</tt> (which is 16 bytes per slice)? Would it be possible to use an 8-byte offset within cl_page (that would still be enough for 256 bytes per slice) similar to <tt>offsetof()</tt> and <tt>container_of()</tt> for accessing the various slices? That alone would save 48 bytes per <tt>cl_page</tt>, depending on how many slices (normally 3 I think), and would likely also be much more CPU efficient than walking a list to get the slice for each layer. </p> <p>We could potentially also remove the <tt>cpl_page</tt> pointer for each <tt>cl_page_slice</tt>, since the layers would always be passed the actual top-level <tt>cl_page</tt> pointer, and use the slice offset within the <tt>cl_page</tt> to access their slice.</p> <p>Another possibility would be to remove/reduce the size of <tt>cpl_ops</tt>. There are only 6 different cl_page_operations types in the code, so storing a 64-bit pointer to identify them is a lot of redundancy. If, for example, each layer would call a simple <tt>cl_register_ops()</tt> function at startup to register the <tt>cl_page_operations</tt> structs in a global array, and then get an index back, then only an 8-bit (or even 3-bit) index needs to be stored for each slice to reference the operations pointer, but all of the layers can still access the global operations array to call those methods if needed.</p> <p>Interesting, yeah, moving all of that to fixed offsets is a good idea.</p> <p>Note that if we're removing cpl_linkage then we'd also remove cp_layers in the top level cl_page_struct, saving another 16 bytes (per cl_page, not per slice).</p> <p>I spent a while with this just now and I didn't find much else that can be dropped, but I did find two things.</p> <p>One thing I considered and rejected: I think the cpl_obj pointer in the slice probably has to stay, because there can be &gt; 1 OSC object associated with a cl_object so there's no simple way to get there from the top level object (without doing an index calculation each time, which seems worse).</p> <p>One thing we can get rid of - since I got inspired to poke around - is cpl_index for the vvp layer, as that's just the vmpage index.  Also, the lov layer is already not using it, it has its own version of that field up in cl_page.  So removing cpl_index from the slice saves us 8 bytes - 4 for the VVP layer, which we don't need, and 4 for the LOV layer, which was already duplicated.  Nothing amazing, but if we're squeezing...</p> <p>In proving to myself that was doable, I wrote a patch for that, so I'll push that in a few.</p> <p> </p> <p>One more I didn't do: Looking at cl_page with pahole, we have two adjacent enums which are both being rendered as 4 byte fields.  (I'm a bit surprised GCC can't evaluate the number of items in an enum and squash them accordingly, but so it goes.)</p> <p>The second enum (page type) is only set at creation and not modified later, so it would be trivial to switch the two enums to an int and use bits rather than the enum.  We would just set the page_type bit (or not set it) at creation time.  We already only set cl_page_state from a function, so just modify that and you're good.</p> <p>Note also that there's a 4 byte hole in cl_page right now as well.  We could move the new enum there.</p> <p>So that's another potential 16 bytes.</p> <p>Ah, hey, here's a slightly trickier one.</p> <p>I think we may be able to do without both cp_owner and cp_sync_io.  I think it's <b>probably</b> possible to... hm.  I'm not 100% sure, but I think the structure of the code is such that we could stick a pointer to cp_sync_io <b>in</b> the owning cl_io.  That assumes, though, that the cl_io has a life time that covers the life time of the anchor, which, well, I haven't checked. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Patrick Farrell (farr0186@gmail.com) uploaded a new patch: <a href="https://review.whamcloud.com/37417" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37417</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> clio: cl_page index compaction<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 0bb04ea7a57b7166a0b9ff458370377dce5674f0</p> <p>tested two patches conjunction with patch <a href="https://jira.whamcloud.com/browse/LU-4198" title="Improve IO performance when using DIRECT IO using libaio" class="issue-link" data-issue-key="LU-4198"><del>LU-4198</del></a>.<br/> <a href="https://review.whamcloud.com/#/c/37227" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/37227</a><br/> <a href="https://review.whamcloud.com/#/c/37225" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/37225</a></p> <p>Single client (2 x Intel(R) Xeon(R) Platinum 8160 CPU @ 2.10GHz, 192GB memory, 2 x IB-EDR) and AI400(20 x NVMe)</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre># fio -name=randread -ioengine=libaio -rw=randread -blocksize=4k -iodepth=128 -direct=1 -size=2g -runtime=60 -numjobs=256 -group_reporting -directory=/ai400/out -create_serialize=0 -filename_format='f.$jobnum.$filenum' </pre> </div></div> <p>4K Random Read</p> <div class='table-wrap'> <table class='confluenceTable'><tbody> <tr> <th class='confluenceTh'> </th> <th class='confluenceTh'>master + <a href="https://jira.whamcloud.com/browse/LU-4198" title="Improve IO performance when using DIRECT IO using libaio" class="issue-link" data-issue-key="LU-4198"><del>LU-4198</del></a></th> <th class='confluenceTh'>master+ <a href="https://jira.whamcloud.com/browse/LU-4198" title="Improve IO performance when using DIRECT IO using libaio" class="issue-link" data-issue-key="LU-4198"><del>LU-4198</del></a> + <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a></th> </tr> <tr> <td class='confluenceTd'>QD=1, numjobs=1</td> <td class='confluenceTd'>4518</td> <td class='confluenceTd'>4538</td> </tr> <tr> <td class='confluenceTd'>QD=128, numjobs=256</td> <td class='confluenceTd'>2177K</td> <td class='confluenceTd'>2207k</td> </tr> </tbody></table> </div> <p>Thanks Ihara for testing!</p> <p>At least we confirm no regression and those patches help reduce memory usage.</p> <p>Thanks <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=adilger" class="user-hover" rel="adilger">adilger</a> and <a href="https://jira.whamcloud.com/secure/ViewProfile.jspa?name=paf0186" class="user-hover" rel="paf0186">paf0186</a> good idea of removing cl_page size, i'll take a look how we could do more.</p> <p>Their is also patch <a href="https://review.whamcloud.com/#/c/30161/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/#/c/30161</a> which was forgotten</p> <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/37428" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37428</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: use offset instead of cp_linkage<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: ab572d7fc10f1ba92ada947d8433cff9f6c74e24</p> <p>This probably needs its own JIRA, etc, but the vvp, osc, and lov <b>page</b> structs could also get a quick look, and I'm going to note that here and let someone else spin off a Jira if they're interested...</p> <p>Looking at vvp_page and lov_page quickly, they seem very minimal.  The OSC page is rather larger.</p> <p>The only obvious thing to remove from osc_page is the ops_submit_time thing - I have never used it, and never previously knew it was there.  I'm not sure it really offers useful functionality above and beyond just using debug logs, etc.</p> <p>So I think that could go.</p> <p>The other members of osc_page all seem necessary, but the packing (from pahole) is... weird.  Some padding, some strange bitfields, etc.  I'm not sure how much it could be improved, but perhaps someone more familiar with packing rules could take a look and see.  (Andreas... <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/wink.png" height="16" width="16" align="absmiddle" alt="" border="0"/> )</p> <p> </p> <p>osc_async_page is a little odd, but I think the 15 'bit' hole isn't a big deal - If we combined the shorts, I believe we'd just end up with a 2 byte hole for alignment, and no gain in space.</p> <p>However, it also has an OSC object pointer, which I believe could be found from the osc_page and the associated slice...?  I am not 100% sure that connects to the same object, but I think it does.</p> <p>So that's another few 10s of bytes of potential space in these structs.</p> <p>We have also <a href="https://jira.whamcloud.com/browse/LU-10994" title="remove unused page layers" class="issue-link" data-issue-key="LU-10994"><del>LU-10994</del></a> which is related.</p> <p>A quick note on my earlier idea of compacting the cp_type and cp_state enum...  That's actually a fair bit of work.  It's relatively simple work, but there are a lot of small moving parts that have to be tweaked.  Just an FYI that it's not as easy as it appears, so unless it's really the difference between squeezing and not squeezing under a limit, those 8 bytes (4 from the removed enum + 4 from better packing) may be better skipped.</p> <blockquote> <p>A quick note on my earlier idea of compacting the cp_type and cp_state enum... That's actually a fair bit of work. It's relatively simple work, but there are a lot of small moving parts that have to be tweaked. Just an FYI that it's not as easy as it appears, so unless it's really the difference between squeezing and not squeezing under a limit, those 8 bytes (4 from the removed enum + 4 from better packing) may be better skipped.</p></blockquote> <p>Acutally, this turns out to be surprisingly easy, and something that I've never known before - it is possible to use "<tt>enum cp_type cp_type:3</tt>" and it will only use 3 bits for the enum. As with any bitfield, it is possible to be racy if updated by multiple threads concurrently, but I don't think that is an issue for the cl_page structures.</p> <p>The "<tt>enum foo:N</tt>" construct seems very useful, and I'd like to start using it in other data structures, instead of having e.g. a "<tt>__u32</tt>" and just a comment that says "this is enum foo".</p> <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/37480" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37480</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: re-declare cl_page variables to reduce its size<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 0fe84824f82bcf1655719b95d23a6f4920cf8af2</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37227/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37227/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: use slab allocation for cl_dio_aio<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 3db1d3322eb0d4271496c6fea169fb10fa500ebb</p> <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/37487" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37487</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> osc: re-declare ops_from/to to shrink osc_page<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 776273c85b3e88ebcd02e616776f4cc97f5d2b23</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37225/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37225/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: use slab allocation for cl_page<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 03364148c01ffe7bb2f2abfde84bbc36dc4d8237</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37417/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37417/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> clio: cl_page index compaction<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: aed166fa29e6f39e53bcc0402ed4875776915a55</p> <p>Wang Shilong (wshilong@ddn.com) uploaded a new patch: <a href="https://review.whamcloud.com/39103" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39103</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> llite: fix to free cl_dio_aio properly<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 43d0d4a9cbce4bf42173f5286bf9ec1e284dfb80</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37428/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37428/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: use offset instead of cp_linkage<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 55967f1e5c7013d2005b38754213babf180e6ea5</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37480/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37480/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> obdclass: re-declare cl_page variables to reduce its size<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 5fb29cd1e77ca7bee34791138b49f5dd50d5116b</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/37487/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/37487/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> osc: re-declare ops_from/to to shrink osc_page<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: 9821754235e2417868dbaeb987b33e22c517346f</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/39103/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/39103/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-13134" title="try to use slab allocation for cl_page" class="issue-link" data-issue-key="LU-13134"><del>LU-13134</del></a> llite: fix to free cl_dio_aio properly<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: f71a539c3e41bae750bcb54b0f9159670148176b</p> Related LU-10257 LU-10994 LU-14711 Development Rank 1|i00rzr: Rank (Obsolete) 9223372036854775807