All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Mingming <cmm@us.ibm.com>
Cc: Holger Kiehl <Holger.Kiehl@dwd.de>, Theodore Tso <tytso@mit.edu>,
	Eric Sandeen <sandeen@redhat.com>, Jan Kara <jack@suse.cz>,
	Solofo.Ramangalahy@bull.net, Nick Dokos <nicholas.dokos@hp.com>,
	linux-ext4@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Performance of ext4
Date: Fri, 27 Jun 2008 14:44:59 +0530	[thread overview]
Message-ID: <20080627091459.GA32723@skywalker> (raw)
In-Reply-To: <1214441199.27507.351.camel@BVR-FS.beaverton.ibm.com>

On Wed, Jun 25, 2008 at 05:46:39PM -0700, Mingming wrote:
> 
> On Wed, 2008-06-25 at 09:09 +0000, Holger Kiehl wrote:
> > On Tue, 24 Jun 2008, Mingming wrote:
> > 
> > >
> > > On Tue, 2008-06-24 at 21:12 +0000, Holger Kiehl wrote:
> > >> Yes, with this patch applied on top of latest patch queue I no longer
> > >> get truncated files, after running a short test. Tomorrow I will do some
> > >> more thorough testing and use the patch you have send to me in a separate
> > >> mail. The above patch did not apply but it was easy to apply by hand.
> > >
> > >
> > > Thanks for quick response and test. I have updated the patch queue with
> > > above patch merged. Please let me know if you still see apply issue and
> > > file size update issue with current patch queue.
> > >
> > Thanks, it applies without any problems. However I still hit an oops. What
> > I find strange is that I got the oops just as the benchmark is done and
> > all process where shutting down. The same behaviour I reported here:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0806.2/2113.html
> > Only this time I got just one oops. This is on x86_64 system (4 Opteron CPU's
> > and SW Raid 1+0). I have not seen this on my home system x86 (1 Dual Core
> > and HW Raid). Anyway, here the dmesg output:
> > 
> > kjournald2 starting.  Commit interval 15 seconds
> > EXT4 FS on md7, internal journal
> > EXT4-fs: mounted filesystem with ordered data mode.
> > EXT4-fs: file extents enabled
> > EXT4-fs: mballoc enabled
> > JBD: barrier-based sync failed on md7 - disabling barriers
> > ------------[ cut here ]------------
> > kernel BUG at fs/ext4/inode.c:1667!
> 
> Did not get a chance to look more closely today, but it's point to this
> code in ext4_da_writepage()
> 
>  page_bufs = page_buffers(page);
> 
> and appearently it's BUG_ON at 
>  BUG_ON(!PagePrivate(page)); in page_buffers().
> 
> 

Ok so we are doing the journal_commit and meanwhile shrink_page_list
dropped the buffer. I guess what is happening is


journal_submit_inode_data_buffers
generic_writepages
write_cache_pages
pagevec_lookup_tag(..PAGECACHE_TAG_DIRTY,..)
foreach(page)
							shrink_page_list
							lock_page
							ext4_releasepage
							try_to_free_buffers
							drop_buffers
							cancel_dirty_page
							unlock_page
lock_page()
BUG_ON(!PagePrivate(page));


How about the below ? I am not sure journalled mode writepage would need a
simillar change. We don't need to redirty the page because
that would mean the next journal_commit will hit the BUG_ON.
If we need to do a BUG_ON

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index fd67b34..94e5ab0 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1662,8 +1662,17 @@ static int ext4_da_writepage(struct page *page,
 		 * writing the page in case we would have to do so.
 		 * We reach here also via journal_submit_inode_data_buffers
 		 */
+		if (!page_has_buffers(page)) {
+			/*
+			 * This can happen when we are called via
+			 * journal_submit_inode_data_buffers and
+			 * shrink_page_list parallely did drop_buffers
+			 * after write_cache_pages did a pagevec_lookup_tag
+			 */
+			unlock_page(page);
+			return 0;
+		}
 		size = i_size_read(inode);

WARNING: multiple messages have this Message-ID (diff)
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
To: Mingming <cmm@us.ibm.com>
Cc: Holger Kiehl <Holger.Kiehl@dwd.de>, Theodore Tso <tytso@mit.edu>,
	Eric Sandeen <sandeen@redhat.com>, Jan Kara <jack@suse.cz>,
	Solofo.Ramangalahy@bull.net, Nick Dokos <nicholas.dokos@hp.com>,
	linux-ext4@vger.kernel.org,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Performance of ext4
Date: Fri, 27 Jun 2008 14:44:59 +0530	[thread overview]
Message-ID: <20080627091459.GA32723@skywalker> (raw)
In-Reply-To: <1214441199.27507.351.camel@BVR-FS.beaverton.ibm.com>

On Wed, Jun 25, 2008 at 05:46:39PM -0700, Mingming wrote:
> 
> On Wed, 2008-06-25 at 09:09 +0000, Holger Kiehl wrote:
> > On Tue, 24 Jun 2008, Mingming wrote:
> > 
> > >
> > > On Tue, 2008-06-24 at 21:12 +0000, Holger Kiehl wrote:
> > >> Yes, with this patch applied on top of latest patch queue I no longer
> > >> get truncated files, after running a short test. Tomorrow I will do some
> > >> more thorough testing and use the patch you have send to me in a separate
> > >> mail. The above patch did not apply but it was easy to apply by hand.
> > >
> > >
> > > Thanks for quick response and test. I have updated the patch queue with
> > > above patch merged. Please let me know if you still see apply issue and
> > > file size update issue with current patch queue.
> > >
> > Thanks, it applies without any problems. However I still hit an oops. What
> > I find strange is that I got the oops just as the benchmark is done and
> > all process where shutting down. The same behaviour I reported here:
> > http://www.ussg.iu.edu/hypermail/linux/kernel/0806.2/2113.html
> > Only this time I got just one oops. This is on x86_64 system (4 Opteron CPU's
> > and SW Raid 1+0). I have not seen this on my home system x86 (1 Dual Core
> > and HW Raid). Anyway, here the dmesg output:
> > 
> > kjournald2 starting.  Commit interval 15 seconds
> > EXT4 FS on md7, internal journal
> > EXT4-fs: mounted filesystem with ordered data mode.
> > EXT4-fs: file extents enabled
> > EXT4-fs: mballoc enabled
> > JBD: barrier-based sync failed on md7 - disabling barriers
> > ------------[ cut here ]------------
> > kernel BUG at fs/ext4/inode.c:1667!
> 
> Did not get a chance to look more closely today, but it's point to this
> code in ext4_da_writepage()
> 
>  page_bufs = page_buffers(page);
> 
> and appearently it's BUG_ON at 
>  BUG_ON(!PagePrivate(page)); in page_buffers().
> 
> 

Ok so we are doing the journal_commit and meanwhile shrink_page_list
dropped the buffer. I guess what is happening is


journal_submit_inode_data_buffers
generic_writepages
write_cache_pages
pagevec_lookup_tag(..PAGECACHE_TAG_DIRTY,..)
foreach(page)
							shrink_page_list
							lock_page
							ext4_releasepage
							try_to_free_buffers
							drop_buffers
							cancel_dirty_page
							unlock_page
lock_page()
BUG_ON(!PagePrivate(page));


How about the below ? I am not sure journalled mode writepage would need a
simillar change. We don't need to redirty the page because
that would mean the next journal_commit will hit the BUG_ON.
If we need to do a BUG_ON

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index fd67b34..94e5ab0 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -1662,8 +1662,17 @@ static int ext4_da_writepage(struct page *page,
 		 * writing the page in case we would have to do so.
 		 * We reach here also via journal_submit_inode_data_buffers
 		 */
+		if (!page_has_buffers(page)) {
+			/*
+			 * This can happen when we are called via
+			 * journal_submit_inode_data_buffers and
+			 * shrink_page_list parallely did drop_buffers
+			 * after write_cache_pages did a pagevec_lookup_tag
+			 */
+			unlock_page(page);
+			return 0;
+		}
 		size = i_size_read(inode);
-
 		page_bufs = page_buffers(page);
 		if (page->index == size >> PAGE_CACHE_SHIFT)
 			len = size & ~PAGE_CACHE_MASK;
@@ -2046,7 +2055,16 @@ static int ext4_normal_writepage(struct page *page,
 	loff_t len;
 
 	J_ASSERT(PageLocked(page));
-	J_ASSERT(page_has_buffers(page));
+	if (!page_has_buffers(page)) {
+		/*
+		 * This can happen when we are called via
+		 * journal_submit_inode_data_buffers and
+		 * shrink_page_list parallely did drop_buffers
+		 * after write_cache_pages did a pagevec_lookup_tag
+		 */
+		unlock_page(page);
+		return 0;
+	}
 	if (page->index == size >> PAGE_CACHE_SHIFT)
 		len = size & ~PAGE_CACHE_MASK;
 	else

  reply	other threads:[~2008-06-27  9:23 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-11  8:02 Performance of ext4 Holger Kiehl
2008-06-11 10:59 ` Aneesh Kumar K.V
2008-06-11 19:58   ` Holger Kiehl
2008-06-11 20:17     ` Nick Dokos
2008-06-12  9:02       ` Holger Kiehl
2008-06-12 10:58         ` Solofo.Ramangalahy
2008-06-12 12:00           ` Holger Kiehl
2008-06-12 13:19             ` Theodore Tso
2008-06-12 14:07               ` Holger Kiehl
2008-06-12 18:06                 ` Aneesh Kumar K.V
2008-06-12 19:50                   ` Holger Kiehl
2008-06-13  8:05                     ` Holger Kiehl
2008-06-16 17:54                       ` Jan Kara
2008-06-16 18:13                         ` Aneesh Kumar K.V
2008-06-17 11:42                           ` Holger Kiehl
2008-06-18  5:58                             ` Holger Kiehl
2008-06-19  6:58                               ` Andreas Dilger
2008-06-19 11:09                               ` Theodore Tso
2008-06-19 15:04                                 ` Holger Kiehl
2008-07-07 13:13                                 ` Holger Kiehl
2008-07-10  8:11                                   ` Holger Kiehl
2008-07-10  9:24                                     ` Aneesh Kumar K.V
2008-07-10  9:26                                       ` Revert Fix-EXT_MAX_BLOCK.patch Aneesh Kumar K.V
2008-07-10 12:22                                         ` Theodore Tso
2008-07-10 12:38                                           ` Aneesh Kumar K.V
2008-07-10 13:02                                             ` Theodore Tso
2008-07-10 12:24                                         ` Theodore Tso
2008-07-11  9:57                                         ` Holger Kiehl
2008-07-11 12:43                                           ` Theodore Tso
2008-07-11 14:57                                             ` Holger Kiehl
2008-07-14 19:55                                             ` Holger Kiehl
2008-07-14 20:28                                               ` Theodore Tso
2008-07-15  6:43                                                 ` Holger Kiehl
2008-06-19 15:56                             ` Performance of ext4 Theodore Tso
2008-06-19 16:41                               ` Eric Sandeen
2008-06-19 16:41                                 ` Eric Sandeen
2008-06-19 17:42                                 ` Theodore Tso
2008-06-19 19:51                                   ` Mingming
2008-06-20  8:32                                   ` Holger Kiehl
2008-06-20  8:59                                     ` Theodore Tso
2008-06-20  9:21                                       ` Holger Kiehl
2008-06-23 17:45                                         ` Aneesh Kumar K.V
2008-06-24  0:31                                           ` Mingming
2008-06-24  0:31                                             ` Mingming
2008-06-24  3:07                                             ` Aneesh Kumar K.V
2008-06-24  3:28                                               ` Aneesh Kumar K.V
2008-06-24  3:33                                               ` Aneesh Kumar K.V
2008-06-24 21:12                                                 ` Holger Kiehl
2008-06-24 22:58                                                   ` Mingming
2008-06-25  9:09                                                     ` Holger Kiehl
2008-06-26  0:46                                                       ` Mingming
2008-06-27  9:14                                                         ` Aneesh Kumar K.V [this message]
2008-06-27  9:14                                                           ` Aneesh Kumar K.V
2008-06-27  9:49                                                           ` Aneesh Kumar K.V
2008-06-27 10:00                                                             ` Jan Kara
2008-06-27 17:35                                                               ` Aneesh Kumar K.V
2008-06-24 17:58                                               ` Mingming
2008-06-24 12:57                                           ` Holger Kiehl
2008-06-23 20:55                                         ` Andreas Dilger
2008-06-20  8:09                               ` Holger Kiehl
2008-06-21 15:02                                 ` Holger Kiehl
2008-06-11 13:54 ` Theodore Tso
2008-06-11 20:21   ` Holger Kiehl
2008-06-12  1:35     ` Theodore Tso

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=20080627091459.GA32723@skywalker \
    --to=aneesh.kumar@linux.vnet.ibm.com \
    --cc=Holger.Kiehl@dwd.de \
    --cc=Solofo.Ramangalahy@bull.net \
    --cc=cmm@us.ibm.com \
    --cc=jack@suse.cz \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nicholas.dokos@hp.com \
    --cc=sandeen@redhat.com \
    --cc=tytso@mit.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.