On Tue, Sep 16, 2014 at 05:07:18PM -0700, Hugh Dickins wrote: > You might (I'm not certain) be able to get away with extending the > use of mlock_vma_page() and munlock_vma_page() in this (admittedly > attractive) way, up until someone mmap's that range (and mlocks > then munlocks it? again, I'm not certain if that's necessary). > Then the PageMlocked flag is liable to be cleared, because the > page will not be found in any mlock'ed vma; and the page can > then be reclaimed behind your back (statistics gone wrong too? > again I'm not sure). > > Now, I expect it's unlikely (impossible?) for anyone to mmap your > bitmap pages while they're being used as filesystem metadata (rather > than mere blockdev pages). But you can see why we would prefer not > to export those functions. Yes, it's impossible for anyone to mmap the pages from EXT4_SB(sb)->s_buddy_cache inode, because it's not exposed in any way to userspace. But I can see why you wouldn't want it to be used almost anywhere else. > For now I agree with Andreas, just grab an extra refcount; but you're > right that leaving these pages on evictable LRUs is regrettable, > and can be inefficient under reclaim. OK, fair enough, that seems simpler all around. Cheers, - Ted -- 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>