All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gioh Kim <gioh.kim@lge.com>
To: Theodore Ts'o <tytso@mit.edu>,
	Peter Zijlstra <peterz@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, Joonsoo Kim <js1304@gmail.com>,
	Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH 0/2] new API to allocate buffer-cache for superblock in non-movable area
Date: Wed, 30 Jul 2014 16:56:27 +0900	[thread overview]
Message-ID: <53D8A52B.5000006@lge.com> (raw)
In-Reply-To: <20140727010144.GA13438@thunk.org>



2014-07-27 오전 10:01, Theodore Ts'o 쓴 글:
> Gioh,
>
> As follow up, if you want some further discussions about why these
> patches should be accepted, it would be good to get some hard data
> about why the keeping the ext4 superblock pinned is causing such a
> problem for page migation.  Can you give us more details about what
> the impact is of not having these patches?  And how it compres to
> other data structures which are currently allocated in the moveable
> area and tend to be pinned effectively indefinitely?
>
> Thanks,
>
> 						- Ted
>

I am very sorry to be late. I couldn't access the network for a week.

sb_bread() allocates page from movable area but the reference count of the buffer-head
that manages page should be zero to migrate the page.
Therefore brelase() should be called immediately after sb_bread() such like fat_fill_super().
But ext4 called brelse() when unmount the superblock.
The page cannot be movable until unmount.
CMA/HOTPLUG memory try to move the page but it fails.

If ext4 needs to keep buffer-cache of superblock until unmount,
it should allocated the page from non-movable area (because it can be a long time).
This patch try to do it.

I also sent an email to Jan Kara. Please refer it.

Thank you for your kindness.
Please inform me if you need any information.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

WARNING: multiple messages have this Message-ID (diff)
From: Gioh Kim <gioh.kim@lge.com>
To: "Theodore Ts'o" <tytso@mit.edu>,
	Peter Zijlstra <peterz@infradead.org>,
	Alexander Viro <viro@zeniv.linux.org.uk>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
	Jan Kara <jack@suse.cz>,
	linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
	Andreas Dilger <adilger.kernel@dilger.ca>,
	linux-ext4@vger.kernel.org, Joonsoo Kim <js1304@gmail.com>,
	Minchan Kim <minchan@kernel.org>
Subject: Re: [PATCH 0/2] new API to allocate buffer-cache for superblock in non-movable area
Date: Wed, 30 Jul 2014 16:56:27 +0900	[thread overview]
Message-ID: <53D8A52B.5000006@lge.com> (raw)
In-Reply-To: <20140727010144.GA13438@thunk.org>



2014-07-27 오전 10:01, Theodore Ts'o 쓴 글:
> Gioh,
>
> As follow up, if you want some further discussions about why these
> patches should be accepted, it would be good to get some hard data
> about why the keeping the ext4 superblock pinned is causing such a
> problem for page migation.  Can you give us more details about what
> the impact is of not having these patches?  And how it compres to
> other data structures which are currently allocated in the moveable
> area and tend to be pinned effectively indefinitely?
>
> Thanks,
>
> 						- Ted
>

I am very sorry to be late. I couldn't access the network for a week.

sb_bread() allocates page from movable area but the reference count of the buffer-head
that manages page should be zero to migrate the page.
Therefore brelase() should be called immediately after sb_bread() such like fat_fill_super().
But ext4 called brelse() when unmount the superblock.
The page cannot be movable until unmount.
CMA/HOTPLUG memory try to move the page but it fails.

If ext4 needs to keep buffer-cache of superblock until unmount,
it should allocated the page from non-movable area (because it can be a long time).
This patch try to do it.

I also sent an email to Jan Kara. Please refer it.

Thank you for your kindness.
Please inform me if you need any information.

  reply	other threads:[~2014-07-30  7:56 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22  5:18 [PATCH 0/2] new API to allocate buffer-cache for superblock in non-movable area Gioh Kim
2014-07-22  7:30 ` Peter Zijlstra
2014-07-22  8:14   ` Theodore Ts'o
2014-07-27  1:01     ` Theodore Ts'o
2014-07-30  7:56       ` Gioh Kim [this message]
2014-07-30  7:56         ` Gioh Kim
2014-07-22  9:38   ` Jan Kara
2014-07-22  9:38     ` Jan Kara
2014-07-30  7:44     ` Gioh Kim
2014-07-30  7:44       ` Gioh Kim
2014-07-30  7:44       ` Gioh Kim
2014-07-30  7:57       ` Kyungmin Park
2014-07-30  7:57         ` Kyungmin Park
2014-07-30 10:11       ` Jan Kara
2014-07-30 10:11         ` Jan Kara
2014-07-30 10:11         ` Jan Kara
2014-07-30 10:19         ` Peter Zijlstra
2014-07-30 23:45           ` Gioh Kim
2014-07-30 23:45             ` Gioh Kim
2014-07-30 23:45             ` Gioh Kim
2014-07-30 23:54         ` Gioh Kim
2014-07-30 23:54           ` Gioh Kim
2014-07-30 23:54           ` Gioh Kim
2014-07-31  0:03           ` Jan Kara
2014-07-31  0:03             ` Jan Kara
2014-07-31  0:03             ` Jan Kara
2014-07-31  0:37             ` Gioh Kim
2014-07-31  0:37               ` Gioh Kim
2014-07-31  0:37               ` Gioh Kim
2014-07-31 12:21               ` Jan Kara
2014-07-31 12:21                 ` Jan Kara
2014-07-31 12:21                 ` Jan Kara
2014-08-01  0:07                 ` Gioh Kim
2014-08-01  0:07                   ` Gioh Kim
2014-08-01  0:07                   ` Gioh Kim
2014-08-01  1:06                   ` Gioh Kim
2014-08-01  1:06                     ` Gioh Kim
2014-08-01  1:06                     ` Gioh Kim
2014-08-01  9:57                     ` Jan Kara
2014-08-01  9:57                       ` Jan Kara
2014-08-01 13:36                       ` Peter Zijlstra
2014-08-01 15:24                         ` Jan Kara
2014-08-01 15:24                           ` Jan Kara
2014-08-01 16:04                           ` Peter Zijlstra
2014-08-06  6:15                             ` Gioh Kim
2014-08-06  6:15                               ` Gioh Kim
2014-08-06  6:15                               ` Gioh Kim
2014-08-01  8:34                 ` Joonsoo Kim
2014-08-01  8:34                   ` Joonsoo Kim
2014-08-01  8:34                   ` Joonsoo Kim
2014-08-01  9:15                   ` Jan Kara
2014-08-01  9:15                     ` Jan Kara
2014-08-01  9:15                     ` Jan Kara

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=53D8A52B.5000006@lge.com \
    --to=gioh.kim@lge.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=akpm@linux-foundation.org \
    --cc=jack@suse.cz \
    --cc=js1304@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=minchan@kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=tytso@mit.edu \
    --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 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.