On Mon 27-11-17 15:26:27, John Hubbard wrote: [...] > Let me add a belated report, then: we ran into this limit while implementing > an early version of Unified Memory[1], back in 2013. The implementation > at the time depended on tracking that assumed "one allocation == one vma". And you tried hard to make those VMAs really separate? E.g. with prot_none gaps? > So, with only 64K vmas, we quickly ran out, and changed the design to work > around that. (And later, the design was *completely* changed to use a separate > tracking system altogether). > > The existing limit seems rather too low, at least from my perspective. Maybe > it would be better, if expressed as a function of RAM size? Dunno. Whenever we tried to do RAM scaling it turned out a bad idea after years when memory grown much more than the code author expected. Just look how we scaled hash table sizes... But maybe you can come up with something clever. In any case tuning this from the userspace is a trivial thing to do and I am somehow skeptical that any early boot code would trip over the limit. -- Michal Hocko SUSE Labs -- 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>
