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 from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
