linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alex Tomas <alex@clusterfs.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: Andreas Dilger <adilger@clusterfs.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Marat Buharov <marat.buharov@gmail.com>,
	Mike Galbraith <efault@gmx.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Jens Axboe <jens.axboe@oracle.com>,
	"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation)
Date: Thu, 03 May 2007 21:38:10 +0400	[thread overview]
Message-ID: <463A1E02.8020506@clusterfs.com> (raw)
In-Reply-To: <20070427151837.f1439639.akpm@linux-foundation.org>

Andrew Morton wrote:
> We can make great improvements here, and I've (twice) previously decribed
> how: hoist the entire ordered-mode data handling out of ext3, and out of
> the buffer_head layer and move it up into the VFS pagecache layer. 
> Basically, do ordered-data with a commit-time inode walk, calling
> do_sync_mapping_range().
> 
> Do it in the VFS.  Make reiserfs use it, remove reiserfs ordered-mode too. 
> Make XFS use it, fix the hey-my-files-are-all-full-of-zeroes problem there.

I'm not sure it's that easy.

if we move to pages, then we have to mark pages to be flushed holding
transaction open. now take delayed allocation into account: we need
to allocate number of blocks at once and then mark all pages mapped,
again within context of the same transaction. so, an implementation
would look like the following?

generic_writepages() {
	/* collect set of contig. dirty pages */
	foo_get_blocks() {
		foo_journal_start();
		foo_new_blocks();
		foo_attach_blocks_to_inode();
		generic_mark_pages_mapped();
		foo_journal_stop();
	}
}

another question is will it scale well given number of dirty inodes
can be much larger than number of inodes with dirty mapped blocks
(in delayed allocation case, for example) ?

thanks, Alex

  reply	other threads:[~2007-05-03 17:38 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1177660767.6567.41.camel@Homer.simpson.net>
2007-04-27  8:33 ` [ext3][kernels >= 2.6.20.7 at least] KDE going comatose when FS is under heavy write load (massive starvation) Andrew Morton
2007-04-27  9:23   ` Mike Galbraith
2007-04-27 10:17   ` Mike Galbraith
2007-04-27 11:59   ` Marat Buharov
2007-04-27 12:30     ` Peter Zijlstra
2007-04-27 13:50       ` Mark Lord
2007-04-27 12:39     ` Manoj Joseph
2007-04-27 15:30     ` Linus Torvalds
2007-04-27 19:31       ` Andreas Dilger
2007-04-27 19:44         ` Mike Galbraith
2007-04-27 19:50         ` Linus Torvalds
2007-04-27 20:05           ` Hua Zhong
2007-04-27 20:12           ` Bill Huey
2007-04-28  5:37             ` Mikulas Patocka
2007-04-28  5:45               ` Mikulas Patocka
2007-04-28 21:57               ` Bill Huey
2007-04-28 22:38                 ` Mikulas Patocka
2007-04-27 20:29           ` Gabriel C
2007-04-27 20:54           ` Manoj Joseph
2007-04-28  8:45           ` Matthias Andree
2007-04-27 22:18         ` Andrew Morton
2007-05-03 17:38           ` Alex Tomas [this message]
2007-05-03 23:54             ` Andrew Morton
2007-05-04  6:18               ` Alex Tomas
2007-05-04  6:38                 ` Andrew Morton
2007-05-04  6:57                   ` Alex Tomas
2007-05-04  7:18                     ` Andrew Morton
2007-05-04  7:39                       ` Alex Tomas
2007-05-04  8:02                         ` Andrew Morton
2007-08-16 18:20                           ` Alex Tomas
2007-08-16 18:46                             ` Andrew Morton
2007-08-17  2:24                               ` Alex Tomas
2007-08-17  6:52                                 ` Andrew Morton
2007-08-17  8:36                                   ` Alex Tomas
2007-08-17  9:02                                     ` Andrew Morton
2007-08-17 18:42                                       ` Alex Tomas
2007-04-28  8:44       ` Matthias Andree
2007-04-28 20:46   ` Mikulas Patocka
2007-04-28 21:12     ` Lee Revell
2007-04-29 20:49       ` Mark Lord

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=463A1E02.8020506@clusterfs.com \
    --to=alex@clusterfs.com \
    --cc=adilger@clusterfs.com \
    --cc=akpm@linux-foundation.org \
    --cc=efault@gmx.de \
    --cc=jens.axboe@oracle.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marat.buharov@gmail.com \
    --cc=torvalds@linux-foundation.org \
    /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).