All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Sam Ben <sam.bennn@gmail.com>
Cc: Dave Hansen <dave@sr71.net>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
Date: Mon, 15 Jul 2013 08:22:16 +0800	[thread overview]
Message-ID: <20130715002216.GA6403@gmail.com> (raw)
In-Reply-To: <51E2173A.8080003@gmail.com>

On Sun, Jul 14, 2013 at 11:12:58AM +0800, Sam Ben wrote:
> On 07/02/2013 10:37 AM, Zheng Liu wrote:
> >On Mon, Jul 01, 2013 at 09:16:46AM -0700, Dave Hansen wrote:
> >>On 06/28/2013 07:20 PM, Zheng Liu wrote:
> >>>>>IOW, a process needing to do a bunch of MAP_POPULATEs isn't
> >>>>>parallelizable, but one using this mechanism would be.
> >>>I look at the code, and it seems that we will handle MAP_POPULATE flag
> >>>after we release mmap_sem locking in vm_mmap_pgoff():
> >>>
> >>>                 down_write(&mm->mmap_sem);
> >>>                 ret = do_mmap_pgoff(file, addr, len, prot, flag, pgoff,
> >>>                                     &populate);
> >>>                 up_write(&mm->mmap_sem);
> >>>                 if (populate)
> >>>                         mm_populate(ret, populate);
> >>>
> >>>Am I missing something?
> >>I went and did my same test using mmap(MAP_POPULATE)/munmap() pair
> >>versus using MADV_POPULATE in 160 threads in parallel.
> >>
> >>MADV_POPULATE was about 10x faster in the threaded configuration.
> >>
> >>With MADV_POPULATE, the biggest cost is shipping the mmap_sem cacheline
> >>around so that we can write the reader count update in to it.  With
> >>mmap(), there is a lot of _contention_ on that lock which is much, much
> >>more expensive than simply bouncing a cacheline around.
> >Thanks for your explanation.
> >
> >FWIW, it would be great if we can let MAP_POPULATE flag support shared
> >mappings because in our product system there has a lot of applications
> >that uses mmap(2) and then pre-faults this mapping.  Currently these
> >applications need to pre-fault the mapping manually.
> 
> How do you pre-fault the mapping manually in your product system? By
> walking through the file touching each page?

Yes, in our product system most applications do like this.

Regards,
                                                - Zheng

--
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: Zheng Liu <gnehzuil.liu@gmail.com>
To: Sam Ben <sam.bennn@gmail.com>
Cc: Dave Hansen <dave@sr71.net>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
Date: Mon, 15 Jul 2013 08:22:16 +0800	[thread overview]
Message-ID: <20130715002216.GA6403@gmail.com> (raw)
In-Reply-To: <51E2173A.8080003@gmail.com>

On Sun, Jul 14, 2013 at 11:12:58AM +0800, Sam Ben wrote:
> On 07/02/2013 10:37 AM, Zheng Liu wrote:
> >On Mon, Jul 01, 2013 at 09:16:46AM -0700, Dave Hansen wrote:
> >>On 06/28/2013 07:20 PM, Zheng Liu wrote:
> >>>>>IOW, a process needing to do a bunch of MAP_POPULATEs isn't
> >>>>>parallelizable, but one using this mechanism would be.
> >>>I look at the code, and it seems that we will handle MAP_POPULATE flag
> >>>after we release mmap_sem locking in vm_mmap_pgoff():
> >>>
> >>>                 down_write(&mm->mmap_sem);
> >>>                 ret = do_mmap_pgoff(file, addr, len, prot, flag, pgoff,
> >>>                                     &populate);
> >>>                 up_write(&mm->mmap_sem);
> >>>                 if (populate)
> >>>                         mm_populate(ret, populate);
> >>>
> >>>Am I missing something?
> >>I went and did my same test using mmap(MAP_POPULATE)/munmap() pair
> >>versus using MADV_POPULATE in 160 threads in parallel.
> >>
> >>MADV_POPULATE was about 10x faster in the threaded configuration.
> >>
> >>With MADV_POPULATE, the biggest cost is shipping the mmap_sem cacheline
> >>around so that we can write the reader count update in to it.  With
> >>mmap(), there is a lot of _contention_ on that lock which is much, much
> >>more expensive than simply bouncing a cacheline around.
> >Thanks for your explanation.
> >
> >FWIW, it would be great if we can let MAP_POPULATE flag support shared
> >mappings because in our product system there has a lot of applications
> >that uses mmap(2) and then pre-faults this mapping.  Currently these
> >applications need to pre-fault the mapping manually.
> 
> How do you pre-fault the mapping manually in your product system? By
> walking through the file touching each page?

Yes, in our product system most applications do like this.

Regards,
                                                - Zheng

  reply	other threads:[~2013-07-15  0:03 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-27 23:16 [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting Dave Hansen
2013-06-27 23:16 ` Dave Hansen
2013-06-28  5:47 ` Zheng Liu
2013-06-28  5:47   ` Zheng Liu
2013-06-28 15:48   ` Dave Hansen
2013-06-28 15:48     ` Dave Hansen
2013-06-29  2:20     ` Zheng Liu
2013-06-29  2:20       ` Zheng Liu
2013-07-01 16:16       ` Dave Hansen
2013-07-01 16:16         ` Dave Hansen
2013-07-02  2:37         ` Zheng Liu
2013-07-02  2:37           ` Zheng Liu
2013-07-02  4:43           ` Dave Hansen
2013-07-02  4:43             ` Dave Hansen
2013-07-02  6:06             ` Zheng Liu
2013-07-02  6:06               ` Zheng Liu
2013-07-14  3:12           ` Sam Ben
2013-07-14  3:12             ` Sam Ben
2013-07-15  0:22             ` Zheng Liu [this message]
2013-07-15  0:22               ` Zheng Liu

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=20130715002216.GA6403@gmail.com \
    --to=gnehzuil.liu@gmail.com \
    --cc=dave@sr71.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=sam.bennn@gmail.com \
    /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.