On 07/20/2015 04:21 PM, Kirill A. Shutemov wrote:
> Currently we don't split huge page on partial unmap. It's not an ideal
> situation. It can lead to memory overhead.
> 
> Furtunately, we can detect partial unmap on page_remove_rmap(). But we
> cannot call split_huge_page() from there due to locking context.
> 
> It's also counterproductive to do directly from munmap() codepath: in
> many cases we will hit this from exit(2) and splitting the huge page
> just to free it up in small pages is not what we really want.
> 
> The patch introduce deferred_split_huge_page() which put the huge page
> into queue for splitting. The splitting itself will happen when we get
> memory pressure via shrinker interface. The page will be dropped from
> list on freeing through compound page destructor.
> 
> Signed-off-by: Kirill A. Shutemov <[email protected]>
> Tested-by: Sasha Levin <[email protected]>
> Tested-by: Aneesh Kumar K.V <[email protected]>
> Acked-by: Vlastimil Babka <[email protected]>

Acked-by: Jerome Marchand <[email protected]>

> ---
>  include/linux/huge_mm.h |   4 ++
>  include/linux/mm.h      |   2 +
>  mm/huge_memory.c        | 127 
> ++++++++++++++++++++++++++++++++++++++++++++++--
>  mm/migrate.c            |   1 +
>  mm/page_alloc.c         |   2 +-
>  mm/rmap.c               |   7 ++-
>  6 files changed, 138 insertions(+), 5 deletions(-)
>


Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to