> However, given the constraints, what's the problem with the mmap > strategy? Sure, you have more page tables on the kernel side, but > mmap'd memory that is never touched is never resident in a process. I > verified this a few months back when troubleshooting some memory-related > issues.
Okeedokee. Can you write up this patch for OSAllocator? > >> (2) POSIX uses MADV_FREE, MADV_DONTNEED, and/or MADV_WILLNEED. I don’t >> think anybody has ever verified that these APIs do what we want. In my >> experience, they usually don’t. So, we need to find a variation on these >> APIs that works and is fast. > > I've looked into it. The MADV_WILLNEED is useless -- it does nothing on > anonymous pages, returns -EINVAL, but is harmless also. The > MADV_DONTNEED dance does work though, properly paging out memory and > lazily providing fresh zeroed pages should the memory be paged in again. The API we want shouldn’t zero the pages or require a page fault right away. It should only zero the pages if they end up being used by the rest of the system. In the normal case, it should return the pages to use intact. Otherwise, it will be too slow, and we’ll have to jump through hoops to avoid using the API very much, which confuses the design. Geoff _______________________________________________ webkit-dev mailing list firstname.lastname@example.org https://lists.webkit.org/mailman/listinfo/webkit-dev