Re: RFC: reviving mlock isolation dead code

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello,

> I would like to resurect this, as I am seeing problems during a large
> mlock (many GB). The mlock takes a long time to complete
> (__mlock_vma_pages_range() is loading pages from disk), there is
> memory pressure as some pages have to be evicted to make room for the
> large mlock, and the LRU algorithm performs badly with the high amount
> of pages still on LRU list - PageMlocked has not been set yet - while
> their VMA is already VM_LOCKED.
> 
> One approach I am considering would be to modify
> __mlock_vma_pages_range() and it call sites so the mmap sem is only
> read-owned while __mlock_vma_pages_range() runs. The mlock handling
> code in try_to_unmap_one() would then be able to acquire the
> mmap_sem() and help, as it is designed to do.

I would like to talk historical story a bit. Originally, Lee designed it as you proposed. 
but Linus refused it. He thought ro-rwsem is bandaid fix. That is one of reason that
some developers seeks proper mmap_sem dividing way.



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxxx  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom policy in Canada: sign http://dissolvethecrtc.ca/
Don't email: <a href


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]