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-9920 Lustre <p>When doing i/o from multiple writers to a single file, the<br/> per-file page cache lock (mapping-&gt;tree_lock) becomes a<br/> bottleneck.</p> <p>Most current uses are single page at a time. This converts<br/> one prominent use, marking page as dirty, to use a pagevec.</p> <p>This improves shared file write performance notably when<br/> many threads are writing to one file.</p> <p>[NB: Detailed numbers coming. Looks like no change in<br/> uncontended case, rising to ~25% for 8 writers.]</p> LU-9920

Use pagevec for marking pages dirty

Bug Minor Resolved Fixed Dongyang Li Patrick Farrell Fri, 25 Aug 2017 16:27:49 +0000 Thu, 22 Oct 2020 06:19:01 +0000 Tue, 1 Oct 2019 03:22:10 +0000 Lustre 2.13.0 0 7 <p>Patrick Farrell (paf@cray.com) uploaded a new patch: <a href="https://review.whamcloud.com/28711" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/28711</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9920" title="Use pagevec for marking pages dirty" class="issue-link" data-issue-key="LU-9920"><del>LU-9920</del></a> vvp: dirty pages with pagevec<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: f30d9cb22e6461f5d5b9325448740518bc46a78c</p> <p>Patrick, a similar issue exists when pages are dropped from cache upon lock cancellation. It would be useful to clean this up to use <tt>invalidate_page_range()</tt> or similar to drop pages from cache (at least in stripe_size chunks) instead of doing it one page at a time as it does today.</p> <p>Andreas,</p> <p>See <a href="https://jira.whamcloud.com/browse/LU-9906" title="Allow Lustre page dropping to use pagevec_release" class="issue-link" data-issue-key="LU-9906"><del>LU-9906</del></a> <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/><br/> And:<br/> <a href="https://review.whamcloud.com/28667" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/28667</a></p> <p>Unlike this patch (which is new and has not run in production), Cray has been using a version of <a href="https://jira.whamcloud.com/browse/LU-9906" title="Allow Lustre page dropping to use pagevec_release" class="issue-link" data-issue-key="LU-9906"><del>LU-9906</del></a> for a while.</p> <p>Ah, sorry, you've already seen that. Still, I think it's the answer to your thought.</p> <p>You are right. I <em>thought</em> I'd seen something similar, but when searching Jira I couldn't find <a href="https://jira.whamcloud.com/browse/LU-9906" title="Allow Lustre page dropping to use pagevec_release" class="issue-link" data-issue-key="LU-9906"><del>LU-9906</del></a> with the keywords I was using. I've now linked these tickets together.</p> <p>As discussed in the gerrit patch for this, the improvement isn't worth the amount of kernel code we have to copy (in slightly modified form).</p> <p>Patrick Farrell (pfarrell@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/35206" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/35206</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9920" title="Use pagevec for marking pages dirty" class="issue-link" data-issue-key="LU-9920"><del>LU-9920</del></a> vvp: dirty pages with pagevec<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: 1<br/> Commit: 2016ba18081a2c7a0efc3829b7e1f06d6054b44c</p> <p>Patrick, is it possible that the high lock contention is a result of something that Lustre is doing under the lock (e.g. per-page lock callbacks or something) or is it conclusive that all of the contention is in the pagecache itself? There is an ongoing discussion in <tt>linux-fsdevel</tt> about page cache scalability w.r.t. concurrent writers, so if there is something we could usefully contribute to the upstream kernel that would help us down the road, now would be a good time to do so.</p> <p>My word, that's quite a thread.  I should've gotten involved a few days ago.  It's also degraded a bit, since Linus and Dave are ... getting along well ... in their most recent notes.</p> <p>I'm going to gather my thoughts/explain a bit here, I know some of this should go on the list, but I've got a lot of catching up to do before I can comment there.</p> <p>So our workload is lots of threads doing buffered i/o to one file*, and we're spending lots of time on spinlocks in two functions:<br/> *I don't know where Kent gets the idea that multiple writers must mean buffered and direct, but that's a sampling from the middle and I have about another hundred messages to read...<br/> (as seen in Ihara's flame graph <a href="https://jira.whamcloud.com/secure/attachment/32772/lustre-ssf.svg" class="external-link" rel="nofollow">https://jira.whamcloud.com/secure/attachment/32772/lustre-ssf.svg</a>)<br/> __add_to_page_cache_locked<br/> and:<br/> __set_page_dirty_nobuffers</p> <p>The particular spinlock is the one that protects the page cache itself.  Used to mapping-&gt;tree_lock, but it's not called a tree any more, so the lock has a new name...  Same lock, though.</p> <p>These functions are both modifying the radix tree/xarray (the data structure used for the page cache was renamed and re-APIed in the last year <span class="error">&#91;no functional changes&#93;</span>) that holds the pages for this particular file.  The first is adding pages, and the second one is tagging radix tree entries as dirty.  (Pages have dirty state, but the radix tree/xarray entries are also tagged as dirty, which is a separate thing, and which allows writeback (mostly writeback) to rapidly find dirty pages.  It is this tagging that needs to write the tree.)</p> <p>In upstream, both of these operations are done a single page at a time, going back several calls.</p> <p>The dirty tagging side is quite simple to do with a pagevec of pages instead, and not release the lock for each page.  This is still tagging one page at a time, but at least it holds the lock.  That's what my patch does - Hold the lock around the loop where the pages are added.  (The latest version takes advantage of Lustre specific behavior to move several operations outside of the lock, an upstream version would look more like the earlier one...  But as Ihara proved, that didn't make much difference anyway.)</p> <p>The xarray/radix tree has the ability to tag pages in batches, but, bizarrely, it's only exposed with a function that does "if have TAG X, add TAG Y", which is used for marking dirty pages for writeback.  There is no way to just batch TAG X (and you can't trick the function either).  It's a slightly bizarre choice and would be very easy to fix with a modification of that function.</p> <p>Briefly put, the adding side is notably more complex to do in batches, mostly because there are a bunch of operations that can potentially fail, and also because the write functions deal with one page at a time, so there's no obvious place to pull in the pages.</p> <p>The core write function in the kernel (generic_perform_write) is a big loop that's basically:<br/> "ask file system for page at offset X"<br/> (this calls .write_begin from the address space ops...)<br/> "copy data to that page"<br/> "tell file system we're done"<br/> (this calls .write_end)<br/> All one page at a time.</p> <p>This is the thing Kent open-coded. He doesn't use write_begin/write_end (though he's basically got versions of them).<br/> He does each step in a separate loop over a bunch of pages each time, but he still gets his pages in the page cache one at a time - So if he allowed multiple writers to a file (I'm guessing he doesn't based on his comments), he'd crash in to the same wall we're hitting. He might get better behavior because he calls the page getting stuff in a tight loop (I have a patch for that I want to play with, but it's complicated.)</p> <p>Like I said, I'll have to pore over that thread carefully, but the straightforward things to do would be:<br/> Allow dirtying with a pagevec</p> <p>Allow bulk tagging in the xarray interface</p> <p>The basic problem with the rest is code complexity, and then getting anything else to benefit.  Without multiple concurrent writers to a single file (so, range locking rather than the inode mutex), there's not really contention on managing the per-file page tracking...  Any benefit experienced by anyone without that would be very small.</p> <p>Oleg Drokin (green@whamcloud.com) merged in patch <a href="https://review.whamcloud.com/28711/" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/28711/</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9920" title="Use pagevec for marking pages dirty" class="issue-link" data-issue-key="LU-9920"><del>LU-9920</del></a> vvp: dirty pages with pagevec<br/> Project: fs/lustre-release<br/> Branch: master<br/> Current Patch Set: <br/> Commit: a7299cb012f8c5574a0cc07ff0e32218fb49d733</p> <p>Landed for 2.13</p> <p>Jian Yu (yujian@whamcloud.com) uploaded a new patch: <a href="https://review.whamcloud.com/40347" class="external-link" target="_blank" rel="nofollow noopener">https://review.whamcloud.com/40347</a><br/> Subject: <a href="https://jira.whamcloud.com/browse/LU-9920" title="Use pagevec for marking pages dirty" class="issue-link" data-issue-key="LU-9920"><del>LU-9920</del></a> vvp: dirty pages with pagevec<br/> Project: fs/lustre-release<br/> Branch: b2_12<br/> Current Patch Set: 1<br/> Commit: b5e6d9840b8515de5102a15a11bc66f95bf25a27</p> Related LU-11290 LU-12429 LU-9906 LU-11775 Development Rank 1|hzzj33: Rank (Obsolete) 9223372036854775807 Severity