linux-kernel - Re: [PATCH] mm: set khugepaged_max_ptes_none by 1/8 of HPAGE_PMD

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.10.1502271248240.2122@chino.kir.corp.google.com>
Date:	Fri, 27 Feb 2015 12:53:37 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Ebru Akagunduz <ebru.akagunduz@...il.com>
cc:	linux-mm@...ck.org, akpm@...ux-foundation.org,
	kirill@...temov.name, mhocko@...e.cz, mgorman@...e.de,
	sasha.levin@...cle.com, hughd@...gle.com, hannes@...xchg.org,
	vbabka@...e.cz, linux-kernel@...r.kernel.org, riel@...hat.com,
	aarcange@...hat.com
Subject: Re: [PATCH] mm: set khugepaged_max_ptes_none by 1/8 of
 HPAGE_PMD_NR

On Fri, 27 Feb 2015, Ebru Akagunduz wrote:

> Using THP, programs can access memory faster, by having the
> kernel collapse small pages into large pages. The parameter
> max_ptes_none specifies how many extra small pages (that are
> not already mapped) can be allocated when collapsing a group
> of small pages into one large page.
> 

Not exactly, khugepaged isn't "allocating" small pages to collapse into a 
hugepage, rather it is allocating a hugepage and then remapping the 
pageblock's mapped pages.

> A larger value of max_ptes_none can cause the kernel
> to collapse more incomplete areas into THPs, speeding
> up memory access at the cost of increased memory use.
> A smaller value of max_ptes_none will reduce memory
> waste, at the expense of collapsing fewer areas into
> THPs.
> 

This changelog only describes what max_ptes_none does, it doesn't state 
why you want to change it from HPAGE_PMD_NR-1, which is 511 on x86_64 
(largest value, more thp), to HPAGE_PMD_NR/8, which is 64 (smaller value, 
less thp, less rss as a result of collapsing).

This has particular performance implications on users who already have thp 
enabled, so it's difficult to change the default.  This is tuanble that 
you could easily set in an initscript, so I don't think we need to change 
the value for everybody.

> The problem was reported here:
> https://bugzilla.kernel.org/show_bug.cgi?id=93111
> 
> Signed-off-by: Ebru Akagunduz <ebru.akagunduz@...il.com>
> Reviewed-by: Rik van Riel <riel@...hat.com>
> ---
>  mm/huge_memory.c | 7 +++----
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index e08e37a..497fb5a 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -59,11 +59,10 @@ static DEFINE_MUTEX(khugepaged_mutex);
>  static DEFINE_SPINLOCK(khugepaged_mm_lock);
>  static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>  /*
> - * default collapse hugepages if there is at least one pte mapped like
> - * it would have happened if the vma was large enough during page
> - * fault.
> + * The default value should be a compromise between memory use and THP speedup.
> + * To collapse hugepages, unmapped ptes should not exceed 1/8 of HPAGE_PMD_NR.
>   */
> -static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR-1;
> +static unsigned int khugepaged_max_ptes_none __read_mostly = HPAGE_PMD_NR/8;
>  
>  static int khugepaged(void *none);
>  static int khugepaged_slab_init(void);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/