From: Zheng Liu <gnehzuil.liu@gmail.com>
To: Dave Hansen <dave@sr71.net>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
Date: Sat, 29 Jun 2013 10:20:01 +0800 [thread overview]
Message-ID: <51CE4451.4060708@gmail.com> (raw)
In-Reply-To: <51CDB056.5090308@sr71.net>
On 06/28/2013 11:48 PM, Dave Hansen wrote:
> On 06/27/2013 10:47 PM, Zheng Liu wrote:
>>> I've been doing some testing involving large amounts of
>>> page cache. It's quite painful to get hundreds of GB
>>> of page cache mapped in, especially when I am trying to
>>> do it in parallel threads. This is true even when the
>>> page cache is already allocated and I only need to map
>>> it in. The test:
>>>
>>> 1. take 160 16MB files
>>> 2. clone 160 threads, mmap the 16MB files, and either
>>> a. walk through the file touching each page
>>
>> Why not change MAP_POPULATE flag in mmap(2)? Now it is only for private
>> mappings. But maybe we could let it support shared mapping.
>
> Adding that support to mmap() will certainly _help_ some folks. But,
> anything that mmap()s something is taking mmap_sem for write. That
> means that threaded apps doing mmap()/munmap() frequently are _not_
> scalable.
>
> 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?
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: Dave Hansen <dave@sr71.net>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH] mm: madvise: MADV_POPULATE for quick pre-faulting
Date: Sat, 29 Jun 2013 10:20:01 +0800 [thread overview]
Message-ID: <51CE4451.4060708@gmail.com> (raw)
In-Reply-To: <51CDB056.5090308@sr71.net>
On 06/28/2013 11:48 PM, Dave Hansen wrote:
> On 06/27/2013 10:47 PM, Zheng Liu wrote:
>>> I've been doing some testing involving large amounts of
>>> page cache. It's quite painful to get hundreds of GB
>>> of page cache mapped in, especially when I am trying to
>>> do it in parallel threads. This is true even when the
>>> page cache is already allocated and I only need to map
>>> it in. The test:
>>>
>>> 1. take 160 16MB files
>>> 2. clone 160 threads, mmap the 16MB files, and either
>>> a. walk through the file touching each page
>>
>> Why not change MAP_POPULATE flag in mmap(2)? Now it is only for private
>> mappings. But maybe we could let it support shared mapping.
>
> Adding that support to mmap() will certainly _help_ some folks. But,
> anything that mmap()s something is taking mmap_sem for write. That
> means that threaded apps doing mmap()/munmap() frequently are _not_
> scalable.
>
> 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?
Regards,
- Zheng
next prev parent reply other threads:[~2013-06-29 2:20 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 [this message]
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
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=51CE4451.4060708@gmail.com \
--to=gnehzuil.liu@gmail.com \
--cc=dave@sr71.net \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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.