On Tue, 2 Apr 2013, Hugh Dickins wrote: > I am strongly in favour of removing that limitation from > __isolate_lru_page() (and the thread you pointed - thank you - shows Mel > and Christoph were both in favour too); and note that there is no such > restriction in the confusingly similar but different isolate_lru_page(). Well the naming could be cleaned up. The fundamental issue with migrating pages is that all references have to be tracked and updates in a way that no references can be followed to invalid or stale page contents. If ramfs does not maintain separate pointers but only relies on pointers already handled by the migration logic then migration is fine. > Some people do worry that migrating Mlocked pages would introduce the > occasional possibility of a minor fault (with migration_entry_wait()) > on an Mlocked region which never faulted before. I tend to dismiss > that worry, but maybe I'm wrong to do so: maybe there should be a > tunable for realtimey people to set, to prohibit page migration from > mlocked areas; but the default should be to allow it. Could we have a different way of marking pages "pinned"? This is useful for various subsystems (like RDMA and various graphics drivers etc) which need to ensure that virtual address to physical address mappings stay the same for a prolonged period of time. I think this use case is becoming more frequent given that offload techniques have to be used these days to overcome the limits on processor performance. > The other reason it looks as if ramfs pages cannot be migrated, is > that it does not set a suitable ->migratepage method, so would be > handled by fallback_migrate_page(), whose PageDirty test will end > up failing the migration with -EBUSY or -EINVAL - if I read it > correctly. These could be handled the same way that anonymous pages are handled. > But until ramfs pages can be migrated, they should not be allocated > with __GFP_MOVABLE. (I've been writing about the migratability of > small pages: I expect you have the migratability of THPages in flux.) I agree. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
