From: Hugh Dickins <hughd@google.com>
To: Ning Qu <quning@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Andrew Morton <akpm@linux-foundation.org>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Andi Kleen <ak@linux.intel.com>,
Matthew Wilcox <matthew.r.wilcox@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Dave Chinner <david@fromorbit.com>, Ning Qu <quning@gmail.com>,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] mm: implement ->map_pages for shmem/tmpfs
Date: Tue, 4 Mar 2014 12:02:15 -0800 (PST) [thread overview]
Message-ID: <alpine.LSU.2.11.1403041143530.1739@eggly.anvils> (raw)
In-Reply-To: <alpine.LSU.2.11.1402281657520.976@eggly.anvils>
On Fri, 28 Feb 2014, Hugh Dickins wrote:
> On Fri, 28 Feb 2014, Ning Qu wrote:
>
> > In shmem/tmpfs, we also use the generic filemap_map_pages,
> > seems the additional checking is not worth a separate version
> > of map_pages for it.
> >
> > Signed-off-by: Ning Qu <quning@google.com>
Acked-by: Hugh Dickins <hughd@google.com>
> > ---
> > mm/shmem.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/mm/shmem.c b/mm/shmem.c
> > index 1f18c9d..2ea4e89 100644
> > --- a/mm/shmem.c
> > +++ b/mm/shmem.c
> > @@ -2783,6 +2783,7 @@ static const struct super_operations shmem_ops = {
> >
> > static const struct vm_operations_struct shmem_vm_ops = {
> > .fault = shmem_fault,
> > + .map_pages = filemap_map_pages,
> > #ifdef CONFIG_NUMA
> > .set_policy = shmem_set_policy,
> > .get_policy = shmem_get_policy,
> > --
>
> (There's no need for a 0/1, all the info should go into the one patch.)
>
> I expect this will prove to be a very sensible and adequate patch,
> thank you: it probably wouldn't be worth more effort to give shmem
> anything special of its own, and filemap_map_pages() is already
> (almost) coping with exceptional entries.
I haven't looked at performance at all: I'm just glad that you and
Kirill have it working correctly as on other filesystems, without
any need for special treatment in filemap_map_pages() - thanks.
>
> But I can't Ack it until I've tested it some more, won't be able to
> do so until Sunday; and even then some doubt, since this and Kirill's
> are built upon mmotm/next, which after a while gives me spinlock
> lockups under load these days, yet to be investigated.
Other test machines didn't give me those lockups at the weekend, and
overnight it looks like yesterday's mmotm has fixed the freezes on my
laptop (PeterZ's "sched: Guarantee task priority in pick_next_task()"
probably fixed them, but it's old history now, so I've not verified).
Hugh
--
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>
next prev parent reply other threads:[~2014-03-04 20:02 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-28 22:18 [PATCH 0/1] mm, shmem: map few pages around fault address if they are in page cache Ning Qu
2014-02-28 22:18 ` [PATCH 1/1] mm: implement ->map_pages for shmem/tmpfs Ning Qu
2014-03-01 1:20 ` Hugh Dickins
2014-03-01 6:36 ` Ning Qu
2014-03-03 11:07 ` Kirill A. Shutemov
2014-03-03 18:49 ` Ning Qu
2014-03-04 20:02 ` Hugh Dickins [this message]
2014-02-28 22:34 ` [PATCH 0/1] mm, shmem: map few pages around fault address if they are in page cache Andrew Morton
2014-02-28 22:35 ` Ning Qu
2014-03-01 0:35 ` Ning Qu
2014-03-01 1:41 ` Andrew Morton
2014-03-01 6:10 ` Ning Qu
2014-03-01 6:27 ` Ning Qu
2014-03-03 22:38 ` Andrew Morton
2014-03-03 23:07 ` Ning Qu
2014-03-03 23:29 ` Linus Torvalds
2014-03-03 23:37 ` Andrew Morton
2014-03-04 0:50 ` Kirill A. Shutemov
2014-03-05 22:20 ` Ning Qu
2014-03-13 20:46 ` Ning Qu
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=alpine.LSU.2.11.1403041143530.1739@eggly.anvils \
--to=hughd@google.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@fromorbit.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.r.wilcox@intel.com \
--cc=mgorman@suse.de \
--cc=quning@gmail.com \
--cc=quning@google.com \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.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;
as well as URLs for NNTP newsgroup(s).