From: Jan Kara <jack@suse.cz>
To: Nick Piggin <npiggin@suse.de>
Cc: Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
david@fromorbit.com, linux-mm@kvack.org
Subject: Re: [PATCH 2/2] mm: Implement writeback livelock avoidance using page tagging
Date: Thu, 10 Jun 2010 10:12:29 +0200 [thread overview]
Message-ID: <20100610081228.GA10827@quack.suse.cz> (raw)
In-Reply-To: <20100607160903.GE6293@quack.scz.novell.com>
On Mon 07-06-10 18:09:03, Jan Kara wrote:
> On Sat 05-06-10 11:38:02, Nick Piggin wrote:
> > On Fri, Jun 04, 2010 at 08:47:11PM +0200, Jan Kara wrote:
> > > done_index = index;
> > > while (!done && (index <= end)) {
> > > int i;
> > >
> > > - nr_pages = pagevec_lookup_tag(&pvec, mapping, &index,
> > > - PAGECACHE_TAG_DIRTY,
> > > + nr_pages = pagevec_lookup_tag(&pvec, mapping, &index, tag,
> > > min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1);
> > > if (nr_pages == 0)
> > > break;
> >
> > Would it be neat to clear the tag even if we didn't set page to
> > writeback? It should be uncommon case.
> Yeah, why not.
Looking at this more, we shouldn't leave any TOWRITE tags dangling in
WB_SYNC_ALL mode - as soon as someone writes the page, he does
set_page_writeback() which clears the tag. Similarly if the page is removed
from the mapping, the tag is cleared. Or am I missing something?
> > > @@ -1319,6 +1356,9 @@ int test_set_page_writeback(struct page *page)
> > > radix_tree_tag_clear(&mapping->page_tree,
> > > page_index(page),
> > > PAGECACHE_TAG_DIRTY);
> > > + radix_tree_tag_clear(&mapping->page_tree,
> > > + page_index(page),
> > > + PAGECACHE_TAG_TOWRITE);
> > > spin_unlock_irqrestore(&mapping->tree_lock, flags);
> > > } else {
> > > ret = TestSetPageWriteback(page);
> >
> > It would be nice to have bitwise tag clearing so we can clear multiple
> > at once. Then
> >
> > clear_tag = PAGECACHE_TAG_TOWRITE;
> > if (!PageDirty(page))
> > clear_tag |= PAGECACHE_TAG_DIRTY;
> >
> > That could reduce overhead a bit more.
> Good idea. Will do.
On a second thought, will it bring us enough to justify a new interface
(which will be inconsistent with all the other radix tree interfaces
because they use tag numbers and not bitmaps)? Because looking at the code,
all we could save is the transformation of page index into a radix tree
path. We would have to do all the other work for each tag separately
anyway and it won't probably have any great cache locality either because
radix trees for different tags are separate.
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2010-06-10 8:12 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-04 18:47 [PATCH 0/2 RFC v3] Livelock avoidance for data integrity writeback Jan Kara
2010-06-04 18:47 ` [PATCH 1/2] radix-tree: Implement function radix_tree_gang_tag_if_tagged Jan Kara
2010-06-04 18:47 ` [PATCH 2/2] mm: Implement writeback livelock avoidance using page tagging Jan Kara
2010-06-05 1:38 ` Nick Piggin
2010-06-07 16:09 ` Jan Kara
2010-06-08 5:29 ` Nick Piggin
2010-06-09 13:04 ` Jan Kara
2010-06-10 8:12 ` Jan Kara [this message]
2010-08-12 18:35 ` Christoph Hellwig
2010-08-12 22:28 ` Jan Kara
2010-08-13 7:50 ` Christoph Hellwig
2010-06-05 1:14 ` [PATCH 0/2 RFC v3] Livelock avoidance for data integrity writeback Nick Piggin
2010-06-06 4:08 ` Wu Fengguang
2010-06-06 7:52 ` Nick Piggin
-- strict thread matches above, loose matches on Subject: below --
2010-06-24 13:57 [PATCH 0/2 v5] Livelock avoidance for data integrity writes Jan Kara
2010-06-24 13:57 ` [PATCH 2/2] mm: Implement writeback livelock avoidance using page tagging Jan Kara
2010-06-16 16:33 Jan Kara
2010-06-16 16:33 ` [PATCH 2/2] mm: Implement writeback livelock avoidance using page tagging Jan Kara
2010-06-18 22:21 ` Andrew Morton
2010-06-21 12:42 ` Jan Kara
2010-06-04 18:40 [PATCH 0/2 RFC v3] Livelock avoidance for data integrity writeback Jan Kara
2010-06-04 18:40 ` [PATCH 2/2] mm: Implement writeback livelock avoidance using page tagging Jan Kara
2010-06-09 23:41 ` Andrew Morton
2010-06-10 12:31 ` Jan Kara
2010-06-09 23:45 ` Andrew Morton
2010-06-10 12:42 ` Jan Kara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100610081228.GA10827@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=npiggin@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).