From: Jan Kara <jack@suse.cz>
To: linux-fsdevel@vger.kernel.org
Cc: linux-mm@kvack.org, Andrew Morton <akpm@linux-foundation.org>,
npiggin@suse.de
Subject: [PATCH 0/2 v4] Writeback livelock avoidance for data integrity writes
Date: Thu, 17 Jun 2010 11:11:57 +0200 [thread overview]
Message-ID: <20100617091156.GB3453@quack.suse.cz> (raw)
In-Reply-To: <1276706031-29421-1-git-send-email-jack@suse.cz>
Sorry for replying to my email but I forgot to set a subject while doing
git send-email. So at least set it now.
Honza
On Wed 16-06-10 18:33:49, Jan Kara wrote:
> Hello,
>
> here is the fourth version of the writeback livelock avoidance patches
> for data integrity writes. To quickly summarize the idea: we tag dirty
> pages at the beginning of write_cache_pages with a new TOWRITE tag and
> then write only tagged pages to avoid parallel writers to livelock us.
> See changelogs of the patches for more details.
> I have tested the patches with fsx and a test program I wrote which
> checks that if we crash after fsync, the data is indeed on disk.
> If there are no more concerns, can these patches get merged?
>
> Honza
>
> Changes since last version:
> - tagging function was changed to stop after given amount of pages to
> avoid keeping tree_lock and irqs disabled for too long
> - changed names and updated comments as Andrew suggested
> - measured memory impact and reported it in the changelog
>
> Things suggested but not changed (I want to avoid going in circles ;):
> - use tagging also for WB_SYNC_NONE writeback - there's problem with an
> interaction with wbc->nr_to_write. If we tag all dirty pages, we can
> spend too much time tagging when we write only a few pages in the end
> because of nr_to_write. If we tag only say nr_to_write pages, we may
> not have enough pages tagged because some pages are written out by
> someone else and so we would have to restart and tagging would become
> essentially useless. So my option is - switch to tagging for WB_SYNC_NONE
> writeback if we can get rid of nr_to_write. But that's a story for
> a different patch set.
> - implement function for clearing several tags (TOWRITE, DIRTY) at once
> - IMHO not worth it because we would save only conversion of page index
> to radix tree offsets. The rest would have to be separate anyways. And
> the interface would be incosistent as well...
> - use __lookup_tag to implement radix_tree_range_tag_if_tagged - doesn't
> quite work because __lookup_tag returns only leaf nodes so we'd have to
> implement tree traversal anyways to tag also internal nodes.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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-17 9:12 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-16 16:33 Jan Kara
2010-06-16 16:33 ` [PATCH 1/2] radix-tree: Implement function radix_tree_range_tag_if_tagged Jan Kara
2010-06-18 22:18 ` Andrew Morton
2010-06-21 12:09 ` Nick Piggin
2010-06-21 22:43 ` Jan Kara
2010-06-23 13:42 ` 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-16 22:15 ` your mail Dave Chinner
2010-06-17 7:43 ` [PATCH 0/2 v4] Writeback livelock avoidance for data integrity writes Jan Kara
2010-06-18 6:11 ` Dave Chinner
2010-06-18 7:01 ` Nick Piggin
2010-06-17 9:11 ` Jan Kara [this message]
2010-06-22 2:59 ` your mail Wu Fengguang
2010-06-22 13:54 ` Jan Kara
2010-06-22 14:12 ` Wu Fengguang
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=20100617091156.GB3453@quack.suse.cz \
--to=jack@suse.cz \
--cc=akpm@linux-foundation.org \
--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).