Hi Dave,
On 19 May 2014 19:50, Dave Hansen wrote:
> We keep the current count as mm->map_count in the kernel, and the limit
> is available because it's a sysctl. It wouldn't be hard to dump
> mm->map_count out in a /proc file somewhere if it would be useful to
> you. Would that work, or is ther
Hi Kirill,
On 19 May 2014 17:53, Kirill A. Shutemov
wrote:
> Is it nessesary to remap in 4k chunks for you?
> What about 64k chunks? Or something bigger?
Good point. We remap chunks of 4k, which is not much, but is already
much larger than the typical object size. Suppose we do such a
remappin
Hi Kirill,
On 19 May 2014 17:17, Kirill A. Shutemov
wrote:
> IIUC PyPy uses the syscall in some early prototype and looks like guys are
> okay to rework it to mmap() if default sysctl_max_map_count will be high
> enough.
Yes, we can switch easily if needed. The syscall is not in any
"production
Hi Sasha,
On 12 May 2014 17:11, Sasha Levin wrote:
> Since we can't find any actual users,
The PyPy project doesn't count as an "actual user"? It's not just an
idea in the air. It's beta code that is already released (and open
source):
http://morepypy.blogspot.ch/2014/04/stm-results-and-secon
Hi Andi,
On 12 May 2014 05:36, Andi Kleen wrote:
>> Here is a note from the PyPy project (mentioned earlier in this
>> thread, and at https://lwn.net/Articles/587923/ ).
>
> Your use is completely bogus. remap_file_pages() pins everything
> and disables any swapping for the area.
? No. Trying t
Hi everybody,
Here is a note from the PyPy project (mentioned earlier in this
thread, and at https://lwn.net/Articles/587923/ ).
Yes, we use remap_file_pages() heavily on the x86-64 architecture.
However, the individual calls to remap_file_pages() are not
performance-critical, so it is easy to sw
6 matches
Mail list logo