[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMSv6X0+3-uNeiyEPD3sA5dA6Af_M+BT0aeVpa3qMv1aga0q9g@mail.gmail.com>
Date: Thu, 8 May 2014 17:44:46 +0200
From: Armin Rigo <arigo@...es.org>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
peterz@...radead.org, mingo@...nel.org
Subject: Re: [PATCHv2 0/2] remap_file_pages() decommission
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 switch to using multiple
mmap()s. We need to perform more measurements to know exactly what
the overhead would be, in terms notably of kernel memory.
However, an issue with that approach is the upper bound on the number
of VMAs. By default, it is not large enough. Right now, it is
possible to remap say 10% of the individual pages from an anonymous
mmap of multiple GBs in size; but doing so with individual calls to
mmap hits this arbitrary limit. I have no particular weight to give
for or against keeping remap_file_pages() in the kernel, but if it is
removed or emulated, it would be a plus if the programs would run on a
machine with the default configuration --- i.e. if you remove or
emulate remap_file_pages(), please increase the default limit as well.
A bientôt,
Armin.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists