On 5/7/05, Hugh Dickins <[EMAIL PROTECTED]> wrote: > > My understanding is that mlock() could in theory allow the page to be moved, > > but that currently nothing in the kernel would actually move it. However, > > that could change in the future to allow hot-swapping of RAM. > > That's my understanding too, that nothing currently does so. Aside from > hot-swapping RAM, there's also a need to be able to migrate pages around > RAM, either to unfragment memory allowing higher-order allocations to > succeed more often, or to get around extreme dmamem/normal-mem/highmem > imbalances without dedicating huge reserves. Those would more often > succeed if uninhibited by mlock.
Hugh, If I am reading you correctly, you are saying that mlock currently prevents pages from migrating around to unfragment memory, but get_user_pages does not prevent this? If this is the case, this could very easily be the problem Timur was experiencing. He is using get_user_pages to lock pages long term (for the life of the process, beyond the bounds of a single system call). If it is possible for a page to be migrated in physical memory during extreme virtual memory pressure while the reference count is held with get_user_pages, that would cause the problem where the hardware is no longer mapped to the same page as the application. BTW: In earlier kernels, I experienced the same issues in our IB drivers when trying to pin pages using only get_user_pages. -- Bill Jordan InfiniCon Systems _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
