linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tommi Rantala <tommi.t.rantala@nokia.com>
To: Tahsin Erdogan <tahsin@google.com>, Theodore Ts'o <tytso@mit.edu>,
	Andreas Dilger <adilger@dilger.ca>
Cc: linux-ext4@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: backporting "ext4: inplace xattr block update fails to deduplicate blocks" to LTS kernels?
Date: Mon, 19 Feb 2018 15:26:37 +0200	[thread overview]
Message-ID: <f3db4b3f-9cb6-c96c-8d31-f2a5f8b4082c@nokia.com> (raw)

Hi,

4.9 (and earlier) LTS kernels are missing this:

commit ec00022030da5761518476096626338bd67df57a
Author: Tahsin Erdogan <tahsin@google.com>
Date:   Sat Aug 5 22:41:42 2017 -0400

     ext4: inplace xattr block update fails to deduplicate blocks


OK to backport it?
I tested it briefly in 4.9, seems to work.

One of our testers noticed a glusterfs performance regression when going 
from 4.4 to 4.9, caused by the duplicated blocks.

In I understand everything correctly, in 4.4 mbcache uses the block 
number in the hash table bucket calculation, and the hash table is 
populated quite evenly even if there are duplicates. So the mbcache is fast.

But in later kernels mbcache puts all the duplicate entries into a 
single bucket. As the entries are stored in one big linked list, this 
obviously makes the mbcache slow.


I tested this in 4.9 (which still has the ext4_xattr_rehash() call that 
got eliminated in commit "ext4: eliminate xattr entry e_hash 
recalculation for removes"):


diff --git a/fs/ext4/xattr.c b/fs/ext4/xattr.c
index 3eeed8f0aa06..3fadfabcac39 100644
--- a/fs/ext4/xattr.c
+++ b/fs/ext4/xattr.c
@@ -837,8 +837,6 @@ ext4_xattr_block_set(handle_t *handle, struct inode 
*inode,
                                 if (!IS_LAST_ENTRY(s->first))
                                         ext4_xattr_rehash(header(s->base),
                                                           s->here);
-                               ext4_xattr_cache_insert(ext4_mb_cache,
-                                       bs->bh);
                         }
                         ext4_xattr_block_csum_set(inode, bs->bh);
                         unlock_buffer(bs->bh);
@@ -959,6 +957,7 @@ ext4_xattr_block_set(handle_t *handle, struct inode 
*inode,
                 } else if (bs->bh && s->base == bs->bh->b_data) {
                         /* We were modifying this block in-place. */
                         ea_bdebug(bs->bh, "keeping this block");
+                       ext4_xattr_cache_insert(ext4_mb_cache, bs->bh);
                         new_bh = bs->bh;
                         get_bh(new_bh);
                 } else {



Tommi

             reply	other threads:[~2018-02-19 13:26 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-19 13:26 Tommi Rantala [this message]
2018-02-21 11:40 ` backporting "ext4: inplace xattr block update fails to deduplicate blocks" to LTS kernels? Greg Kroah-Hartman
2018-02-21 15:56   ` Theodore Ts'o
2018-02-22 13:37     ` Tommi Rantala

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=f3db4b3f-9cb6-c96c-8d31-f2a5f8b4082c@nokia.com \
    --to=tommi.t.rantala@nokia.com \
    --cc=adilger@dilger.ca \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tahsin@google.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 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).