From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1164983AbdDXFLl convert rfc822-to-8bit (ORCPT ); Mon, 24 Apr 2017 01:11:41 -0400 Received: from mail.kernel.org ([198.145.29.136]:37150 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751805AbdDXFLe (ORCPT ); Mon, 24 Apr 2017 01:11:34 -0400 MIME-Version: 1.0 In-Reply-To: <030ea57b-5f6c-13d8-02f7-b245a754a87d@physik.fu-berlin.de> References: <030ea57b-5f6c-13d8-02f7-b245a754a87d@physik.fu-berlin.de> From: Andy Lutomirski Date: Sun, 23 Apr 2017 22:11:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Question on the five-level page table support patches To: John Paul Adrian Glaubitz Cc: "Kirill A. Shutemov" , "linux-kernel@vger.kernel.org" , Andi Kleen , Dave Hansen , Michal Hocko , linux-arch , "linux-mm@kvack.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Apr 23, 2017 at 3:53 AM, John Paul Adrian Glaubitz wrote: > Hi Kirill! > > I recently read the LWN article on your and your colleagues work to > add five-level page table support for x86 to the Linux kernel [1] > and I got your email address from the last patch of the series. > > Since this extends the address space beyond 48-bits, as you may know, > it will cause potential headaches with Javascript engines which use > tagged pointers. On SPARC, the virtual address space already extends > to 52 bits and we are running into these very issues with Javascript > engines on SPARC. > > Now, a possible way to mitigate this problem would be to pass the > "hint" parameter to mmap() in order to tell the kernel not to allocate > memory beyond the 48 bits address space. Unfortunately, on Linux this > will only work when the area pointed to by "hint" is unallocated which > means one cannot simply use a hardcoded "hint" to mitigate this problem. > > However, since this trick still works on NetBSD and used to work on > Linux [3], I was wondering whether there are plans to bring back > this behavior to mmap() in Linux. > > Currently, people are using ugly work-arounds [4] to address this > problem which involve a manual iteration over memory blocks and > basically implementing another allocator in the user space > application. > > Thanks, > Adrian > >> [1] https://lwn.net/Articles/717293/ >> [2] https://lwn.net/Articles/717300/ >> [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824449#22 >> [4] https://hg.mozilla.org/mozilla-central/rev/dfaafbaaa291 > Can you explain what the issue is? What used to work on Linux and doesn't any more? The man page is quite clear: MAP_FIXED Don't interpret addr as a hint: place the mapping at exactly that address. addr must be a multiple of the page size. If the memory region specified by addr and len overlaps pages of any existing mapping(s), then the overlapped part of the existing mapping(s) will be discarded. If the specified address cannot be used, mmap() will fail. Because requiring a fixed address for a mapping is less portable, the use of this option is dis‐ couraged. and AFAIK Linux works exactly as documented. FWIW, a patch to add a new MAP_ mode to tell mmap(2) to use the hinted address if available and to *fail* if the hinted address is not available would very likely be accepted and would IMO be much nicer than the current behavior. --Andy