From: Ted Ts'o <tytso@mit.edu>
To: Eric Sandeen <sandeen@redhat.com>
Cc: ext4 development <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 3/3] ext4: update writeback_index based on last page scanned
Date: Tue, 26 Oct 2010 10:14:54 -0400 [thread overview]
Message-ID: <20101026141454.GL16981@thunk.org> (raw)
In-Reply-To: <4CC5F8FE.6000100@redhat.com>
On Mon, Oct 25, 2010 at 04:39:10PM -0500, Eric Sandeen wrote:
>
> Not compilebench specifically, but I did do some benchmarking
> with out of cache buffered IO; to be honest I didn't see
> striking performance differences, but I did see the writeback
> behave better in terms of not wandering all over, even if it
> might recover well.
>
> I can try compilebench; do you have specific concerns?
My specific concern is that what happens if __mpage_da_writepage()
accumulates 200 pages, but then we were only able to accumulate 50
pages, and we only write 50 pages.
In the long run what I really want to do is to not call
clear_page_dirty_for_io() in the renamed write_cache_pages_da(), but
rather be as greedy as possible about finding dirty/delayed allocate
pages, and then try to allocate pages for all of them.
We would then scan the pages for PAGECACHE_TAG_TOWRITE in
mpage_submit_data_io(), and then write out whatever number of pages we
need. At that point we will be a good citizen and writing back what
the writeback system asks of us --- but we'll be allocating as much
pages as possible so that the block allocations are sane. (At that
point we may find out that the core writeback is screwing us because
it's not asking us to write back enough; note that XFS decides on its
own how many pages to writeback in the first call to xfs_writepage(),
and even if writeback is silly enough to think that XFS should write
4MB, then switch to another inode, write 4MB, then write to another
inode, etc., XFS ignores what writeback asks of it. But we'll cross
that road when we get to it....)
So the bottom line is that I believe that what we were doing before is
wrong; and what we're doing is still wrong, even after your patches.
I just want to make sure that our performance doesn't go crashing
through the floor in order to avoid the livelock problem. (Which I
agree is a real problem, but we've lived it for quite a while, and I
haven't seen any evidence of it showing up in production.)
- Ted
next prev parent reply other threads:[~2010-10-26 14:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-22 21:29 [PATCH 0/3] ext4: minor writeback changes Eric Sandeen
2010-10-22 21:30 ` [PATCH 1/3] ext4: tidy up a void argument in inode.c Eric Sandeen
2010-10-22 21:37 ` [PATCH 2/3] ext4: implement writeback livelock avoidance using page tagging Eric Sandeen
2010-10-22 21:45 ` [PATCH 3/3] ext4: update writeback_index based on last page scanned Eric Sandeen
2010-10-25 21:35 ` Ted Ts'o
2010-10-25 21:39 ` Eric Sandeen
2010-10-26 14:14 ` Ted Ts'o [this message]
2010-10-26 14:57 ` Eric Sandeen
2010-10-26 18:59 ` Ted Ts'o
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=20101026141454.GL16981@thunk.org \
--to=tytso@mit.edu \
--cc=linux-ext4@vger.kernel.org \
--cc=sandeen@redhat.com \
/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).