Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932094AbbB0U5a (ORCPT ); Fri, 27 Feb 2015 15:57:30 -0500 Received: from mx1.redhat.com ([209.132.183.28]:50679 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755243AbbB0U52 (ORCPT ); Fri, 27 Feb 2015 15:57:28 -0500 Message-ID: <54F0DA1E.9060006@redhat.com> Date: Fri, 27 Feb 2015 15:57:02 -0500 From: Rik van Riel User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: David Rientjes , Ebru Akagunduz CC: linux-mm@kvack.org, akpm@linux-foundation.org, kirill@shutemov.name, mhocko@suse.cz, mgorman@suse.de, sasha.levin@oracle.com, hughd@google.com, hannes@cmpxchg.org, vbabka@suse.cz, linux-kernel@vger.kernel.org, aarcange@redhat.com Subject: Re: [PATCH] mm: set khugepaged_max_ptes_none by 1/8 of HPAGE_PMD_NR References: <1425061608-15811-1-git-send-email-ebru.akagunduz@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2276 Lines: 60 On 02/27/2015 03:53 PM, David Rientjes wrote: > 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. How would you describe the amount of extra memory allocated, as a result of converting a partially mapped 2MB area into a THP? It is not physically allocating 4kB pages, but I would like to keep the text understandable to people who do not know the THP internals. >> 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. I think we do need to change the default. Why? See this bug: >> The problem was reported here: >> https://bugzilla.kernel.org/show_bug.cgi?id=93111 Now, there may be a better value than HPAGE_PMD_NR/8, but I am not sure what it would be, or why. I do know that HPAGE_PMD_NR-1 results in undesired behaviour, as seen in the bug above... -- All rights reversed -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/