From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Andres Lagar-Cavilla <andreslc@google.com>,
Yang Shi <yang.shi@linaro.org>, Ning Qu <quning@gmail.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
kernel test robot <xiaolong.ye@intel.com>,
Xiong Zhou <jencce.kernel@gmail.com>,
Matthew Wilcox <willy@linux.intel.com>,
Greg Thelen <gthelen@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH mmotm 5/5] huge tmpfs: add shmem_pmd_fault()
Date: Sun, 17 Apr 2016 03:46:26 +0300 [thread overview]
Message-ID: <20160417004626.GA5169@node.shutemov.name> (raw)
In-Reply-To: <alpine.LSU.2.11.1604161638230.1907@eggly.anvils>
On Sat, Apr 16, 2016 at 04:41:33PM -0700, Hugh Dickins wrote:
> The pmd_fault() method gives the filesystem an opportunity to place
> a trans huge pmd entry at *pmd, before any pagetable is exposed (and
> an opportunity to split it on COW fault): now use it for huge tmpfs.
>
> This patch is a little raw: with more time before LSF/MM, I would
> probably want to dress it up better - the shmem_mapping() calls look
> a bit ugly; it's odd to want FAULT_FLAG_MAY_HUGE and VM_FAULT_HUGE just
> for a private conversation between shmem_fault() and shmem_pmd_fault();
> and there might be a better distribution of work between those two, but
> prising apart that series of huge tests is not to be done in a hurry.
>
> Good for now, presents the new way, but might be improved later.
>
> This patch still leaves the huge tmpfs map_team_by_pmd() allocating a
> pagetable while holding page lock, but other filesystems are no longer
> doing so; and we've not yet settled whether huge tmpfs should (like anon
> THP) or should not (like DAX) participate in deposit/withdraw protocol.
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
Just for record: I don't like ->pmd_fault() approach because it results in
two requests to file system (two shmem_fault() in this case) if we don't
have a huge page to map: one for huge page (failed) and then one for small.
I think this case should be rather common: all mounts without huge pages
enabled. I expect performance regression from this too.
--
Kirill A. Shutemov
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: "Kirill A. Shutemov" <kirill@shutemov.name>
To: Hugh Dickins <hughd@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Andres Lagar-Cavilla <andreslc@google.com>,
Yang Shi <yang.shi@linaro.org>, Ning Qu <quning@gmail.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
kernel test robot <xiaolong.ye@intel.com>,
Xiong Zhou <jencce.kernel@gmail.com>,
Matthew Wilcox <willy@linux.intel.com>,
Greg Thelen <gthelen@google.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH mmotm 5/5] huge tmpfs: add shmem_pmd_fault()
Date: Sun, 17 Apr 2016 03:46:26 +0300 [thread overview]
Message-ID: <20160417004626.GA5169@node.shutemov.name> (raw)
In-Reply-To: <alpine.LSU.2.11.1604161638230.1907@eggly.anvils>
On Sat, Apr 16, 2016 at 04:41:33PM -0700, Hugh Dickins wrote:
> The pmd_fault() method gives the filesystem an opportunity to place
> a trans huge pmd entry at *pmd, before any pagetable is exposed (and
> an opportunity to split it on COW fault): now use it for huge tmpfs.
>
> This patch is a little raw: with more time before LSF/MM, I would
> probably want to dress it up better - the shmem_mapping() calls look
> a bit ugly; it's odd to want FAULT_FLAG_MAY_HUGE and VM_FAULT_HUGE just
> for a private conversation between shmem_fault() and shmem_pmd_fault();
> and there might be a better distribution of work between those two, but
> prising apart that series of huge tests is not to be done in a hurry.
>
> Good for now, presents the new way, but might be improved later.
>
> This patch still leaves the huge tmpfs map_team_by_pmd() allocating a
> pagetable while holding page lock, but other filesystems are no longer
> doing so; and we've not yet settled whether huge tmpfs should (like anon
> THP) or should not (like DAX) participate in deposit/withdraw protocol.
>
> Signed-off-by: Hugh Dickins <hughd@google.com>
Just for record: I don't like ->pmd_fault() approach because it results in
two requests to file system (two shmem_fault() in this case) if we don't
have a huge page to map: one for huge page (failed) and then one for small.
I think this case should be rather common: all mounts without huge pages
enabled. I expect performance regression from this too.
--
Kirill A. Shutemov
next prev parent reply other threads:[~2016-04-17 0:46 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-16 23:27 [PATCH mmotm 1/5] huge tmpfs: try to allocate huge pages split into a team fix Hugh Dickins
2016-04-16 23:27 ` Hugh Dickins
2016-04-16 23:29 ` [PATCH mmotm 2/5] huge tmpfs: fix mlocked meminfo track huge unhuge mlocks fix Hugh Dickins
2016-04-16 23:29 ` Hugh Dickins
2016-04-20 23:48 ` Stephen Rothwell
2016-04-20 23:48 ` Stephen Rothwell
2016-04-16 23:33 ` [PATCH mmotm 3/5] huge tmpfs recovery: tweak shmem_getpage_gfp to fill team fix Hugh Dickins
2016-04-16 23:33 ` Hugh Dickins
2016-04-20 23:50 ` Stephen Rothwell
2016-04-20 23:50 ` Stephen Rothwell
2016-04-16 23:38 ` [PATCH mmotm 4/5] huge tmpfs: avoid premature exposure of new pagetable revert Hugh Dickins
2016-04-16 23:38 ` Hugh Dickins
2016-04-20 23:55 ` Stephen Rothwell
2016-04-20 23:55 ` Stephen Rothwell
2016-04-16 23:41 ` [PATCH mmotm 5/5] huge tmpfs: add shmem_pmd_fault() Hugh Dickins
2016-04-16 23:41 ` Hugh Dickins
2016-04-17 0:46 ` Kirill A. Shutemov [this message]
2016-04-17 0:46 ` Kirill A. Shutemov
2016-04-17 1:21 ` Hugh Dickins
2016-04-17 1:21 ` Hugh Dickins
2016-04-20 23:56 ` Stephen Rothwell
2016-04-20 23:56 ` Stephen Rothwell
2016-04-20 23:45 ` [PATCH mmotm 1/5] huge tmpfs: try to allocate huge pages split into a team fix Stephen Rothwell
2016-04-20 23:45 ` Stephen Rothwell
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=20160417004626.GA5169@node.shutemov.name \
--to=kirill@shutemov.name \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=andreslc@google.com \
--cc=gthelen@google.com \
--cc=hughd@google.com \
--cc=jencce.kernel@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=quning@gmail.com \
--cc=sfr@canb.auug.org.au \
--cc=willy@linux.intel.com \
--cc=xiaolong.ye@intel.com \
--cc=yang.shi@linaro.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 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.