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@xxxxxxxxxx>
Acked-by: Hugh Dickins <hughd@xxxxxxxxxx>
> > ---
> > 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 from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
