linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Konstantin Khlebnikov <koct9i@gmail.com>
To: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [PATCH] fs: avoid locking sb_lock in grab_super_passive()
Date: Fri, 20 Feb 2015 00:06:51 +0300	[thread overview]
Message-ID: <CALYGNiPwR8Qy2iHrSSYyJXxE8eAn4PuK5a+u4XtWS2dFjwNqjw@mail.gmail.com> (raw)
In-Reply-To: <20150219171934.20458.30175.stgit@buzz>

On Thu, Feb 19, 2015 at 8:19 PM, Konstantin Khlebnikov
<khlebnikov@yandex-team.ru> wrote:
> I've noticed significant locking contention in memory reclaimer around
> sb_lock inside grab_super_passive(). Grab_super_passive() is called from
> two places: in icache/dcache shrinkers (function super_cache_scan) and
> from writeback (function __writeback_inodes_wb). Both are required for
> progress in memory reclaimer.
>
> Also this lock isn't irq-safe. And I've seen suspicious livelock under
> serious memory pressure where reclaimer was called from interrupt which

s/reclaimer/allocator/

> have happened right in place where sb_lock is held in normal context,
> so all other cpus were stuck on that lock too.
>
> Grab_super_passive() acquires sb_lock to increment sb->s_count and check
> sb->s_instances. It seems sb->s_umount locked for read is enough here:
> super-block deactivation always runs under sb->s_umount locked for write.
> Protecting super-block itself isn't a problem: in super_cache_scan() sb
> is protected by shrinker_rwsem: it cannot be freed if its slab shrinkers
> are still active. Inside writeback super-block comes from inode from bdi
> writeback list under wb->list_lock.
>
> This patch removes locking sb_lock and checks s_instances under s_umount:
> generic_shutdown_super() unlinks it under sb->s_umount locked for write.
> Now successful grab_super_passive() only locks semaphore, callers must
> call up_read(&sb->s_umount) instead of drop_super(sb) when they're done.
>
> Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
> ---
>  fs/fs-writeback.c |    2 +-
>  fs/super.c        |   18 ++++--------------
>  2 files changed, 5 insertions(+), 15 deletions(-)
>
> diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
> index 073657f..3e92bb7 100644
> --- a/fs/fs-writeback.c
> +++ b/fs/fs-writeback.c
> @@ -779,7 +779,7 @@ static long __writeback_inodes_wb(struct bdi_writeback *wb,
>                         continue;
>                 }
>                 wrote += writeback_sb_inodes(sb, wb, work);
> -               drop_super(sb);
> +               up_read(&sb->s_umount);
>
>                 /* refer to the same tests at the end of writeback_sb_inodes */
>                 if (wrote) {
> diff --git a/fs/super.c b/fs/super.c
> index 65a53ef..6ae33ed 100644
> --- a/fs/super.c
> +++ b/fs/super.c
> @@ -105,7 +105,7 @@ static unsigned long super_cache_scan(struct shrinker *shrink,
>                 freed += sb->s_op->free_cached_objects(sb, sc);
>         }
>
> -       drop_super(sb);
> +       up_read(&sb->s_umount);
>         return freed;
>  }
>
> @@ -356,27 +356,17 @@ static int grab_super(struct super_block *s) __releases(sb_lock)
>   *     superblock does not go away while we are working on it. It returns
>   *     false if a reference was not gained, and returns true with the s_umount
>   *     lock held in read mode if a reference is gained. On successful return,
> - *     the caller must drop the s_umount lock and the passive reference when
> - *     done.
> + *     the caller must drop the s_umount lock when done.
>   */
>  bool grab_super_passive(struct super_block *sb)
>  {
> -       spin_lock(&sb_lock);
> -       if (hlist_unhashed(&sb->s_instances)) {
> -               spin_unlock(&sb_lock);
> -               return false;
> -       }
> -
> -       sb->s_count++;
> -       spin_unlock(&sb_lock);
> -
>         if (down_read_trylock(&sb->s_umount)) {
> -               if (sb->s_root && (sb->s_flags & MS_BORN))
> +               if (!hlist_unhashed(&sb->s_instances) &&
> +                   sb->s_root && (sb->s_flags & MS_BORN))
>                         return true;
>                 up_read(&sb->s_umount);
>         }
>
> -       put_super(sb);
>         return false;
>  }
>
>
> --
> 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>

--
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>

  reply	other threads:[~2015-02-19 21:06 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-19 17:19 Konstantin Khlebnikov
2015-02-19 21:06 ` Konstantin Khlebnikov [this message]
2015-02-20 23:07 ` Andrew Morton
2015-02-20 23:50   ` Al Viro
2015-02-24 10:41     ` Konstantin Khlebnikov
2015-02-21  2:37 ` Al Viro
2015-02-24  9:19   ` Konstantin Khlebnikov

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=CALYGNiPwR8Qy2iHrSSYyJXxE8eAn4PuK5a+u4XtWS2dFjwNqjw@mail.gmail.com \
    --to=koct9i@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=viro@zeniv.linux.org.uk \
    /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