• Hugh Dickins's avatar
    ksm: memory hotremove migration only · 62b61f61
    Hugh Dickins authored
    The previous patch enables page migration of ksm pages, but that soon gets
    into trouble: not surprising, since we're using the ksm page lock to lock
    operations on its stable_node, but page migration switches the page whose
    lock is to be used for that.  Another layer of locking would fix it, but
    do we need that yet?
    
    Do we actually need page migration of ksm pages?  Yes, memory hotremove
    needs to offline sections of memory: and since we stopped allocating ksm
    pages with GFP_HIGHUSER, they will tend to be GFP_HIGHUSER_MOVABLE
    candidates for migration.
    
    But KSM is currently unconscious of NUMA issues, happily merging pages
    from different NUMA nodes: at present the rule must be, not to use
    MADV_MERGEABLE where you care about NUMA.  So no, NUMA page migration of
    ksm pages does not make sense yet.
    
    So, to complete support for ksm swapping we need to make hotremove safe.
    ksm_memory_callback() take ksm_thread_mutex when MEM_GOING_OFFLINE and
    release it when MEM_OFFLINE or MEM_...
    62b61f61
mempolicy.c 62.5 KB