On Wed, Jun 22, 2016 at 10:53:50AM -0400, Christopher Covington wrote: > +Andy, Cyrill, Dmitry who have been discussing variable TASK_SIZE on x86 > on linux-mm > > http://marc.info/?l=linux-mm&m=146290118818484&w=2 > > >>> On 04/28/2016 09:00 AM, Maxim Kuvyrkov wrote: > >>>> This is a summary of discussions we had on IRC between kernel and > >>>> toolchain engineers regarding support for JITs and 52-bit virtual > >>>> address space (mostly in the context of LuaJIT, but this concerns other > >>>> JITs too). > >>>> > >>>> The summary is that we need to consider ways of reducing the size of > >>>> VA for a given process or container on a Linux system. > >>>> > >>>> The high-level problem is that JITs tend to use upper bits of > >>>> addresses to encode various pieces of data, and that the number of > >>>> available bits is shrinking due to VA size increasing. With the usual > >>>> 42-bit VA (which is what most JITs assume) they have 22 bits to encode > >>>> various performance-critical data. With 48-bit VA (e.g., ThunderX world) > >>>> things start to get complicated, and JITs need to be non-trivially > >>>> patched at the source level to continue working with less bits available > >>>> for their performance-critical storage. With upcoming 52-bit VA things > >>>> might get dire enough for some JITs to declare such configurations > >>>> unsupported. > >>>> > >>>> On the other hand, most JITs are not expected to requires terabytes > >>>> of RAM and huge VA for their applications. Most JIT applications will > >>>> happily live in 42-bit world with mere 4 terabytes of RAM that it > >>>> provides. Therefore, what JITs need in the modern world is a way to make > >>>> mmap() return addresses below a certain threshold, and error out with > >>>> ENOMEM when "lower" memory is exhausted. This is very similar to > >>>> ADDR_LIMIT_32BIT personality, but extended to common VA sizes on 64-bit > >>>> systems: 39-bit, 42-bit, 48-bit, 52-bit, etc. > >>>> > >>>> Since we do not want to penalize the whole system (using an > >>>> artificially low-size VA), it would be best to have a way to enable VA > >>>> limit on per-process basis (similar to ADDR_LIMIT_32BIT personality). If > >>>> that's not possible -- then on per-container / cgroup basis. If that's > >>>> not possible -- then on system level (similar to vm.mmap_min_addr, but > >>>> from the other end). > >>>> > >>>> Dear kernel people, what can be done to address the JITs need to > >>>> reduce effective VA size? What about, by default, keep applications within known-to-be-safe VA size and require explicit opt-in for larger one. The opt-in can be provided in few forms: personality()/prctl() or ELF flag. I think it's reasonable to set the large-VA ELF flag for newly compiled binaries (unless specified otherwise). So they can benefit from larger VA size, but existing binaries woundn't break. I believe we had something similar for non-executable stack transition. -- Kirill A. Shutemov -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>