From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1758137AbbCERBN (ORCPT <rfc822;w@1wt.eu>);
	Thu, 5 Mar 2015 12:01:13 -0500
Received: from cantor2.suse.de ([195.135.220.15]:49531 "EHLO mx2.suse.de"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750834AbbCERBM (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Thu, 5 Mar 2015 12:01:12 -0500
Message-ID: <54F88BD4.3090006@suse.cz>
Date: Thu, 05 Mar 2015 18:01:08 +0100
From: Vlastimil Babka <vbabka@suse.cz>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Andres Freund <andres@anarazel.de>
CC: Andrew Morton <akpm@linux-foundation.org>,
        Davidlohr Bueso <dave@stgolabs.net>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Hugh Dickins <hughd@google.com>,
        Andrea Arcangeli <aarcange@redhat.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Rik van Riel <riel@redhat.com>, Mel Gorman <mgorman@suse.de>,
        Michal Hocko <mhocko@suse.cz>,
        Ebru Akagunduz <ebru.akagunduz@gmail.com>,
        Alex Thorlton <athorlton@sgi.com>,
        David Rientjes <rientjes@google.com>,
        Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        Robert Haas <robertmhaas@gmail.com>, Josh Berkus <josh@agliodbs.com>
Subject: Re: [RFC 0/6] the big khugepaged redesign
References: <1424696322-21952-1-git-send-email-vbabka@suse.cz> <1424731603.6539.51.camel@stgolabs.net> <20150223145619.64f3a225b914034a17d4f520@linux-foundation.org> <54EC533E.8040805@suse.cz> <54F88498.2000902@suse.cz> <20150305165230.GQ30405@awork2.anarazel.de>
In-Reply-To: <20150305165230.GQ30405@awork2.anarazel.de>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On 03/05/2015 05:52 PM, Andres Freund wrote:
> Hi,
> 
> On 2015-03-05 17:30:16 +0100, Vlastimil Babka wrote:
>> That however means the workload is based on hugetlbfs and shouldn't trigger THP
>> page fault activity, which is the aim of this patchset. Some more googling made
>> me recall that last LSF/MM, postgresql people mentioned THP issues and pointed
>> at compaction. See http://lwn.net/Articles/591723/ That's exactly where this
>> patchset should help, but I obviously won't be able to measure this before LSF/MM...
>> 
>> I'm CCing the psql guys from last year LSF/MM - do you have any insight about
>> psql performance with THPs enabled/disabled on recent kernels, where e.g.
>> compaction is no longer synchronous for THP page faults?
> 
> What exactly counts as "recent" in this context? Most of the bigger
> installations where we found THP to be absolutely prohibitive (slowdowns
> on the order of a magnitude, huge latency spikes) unfortunately run
> quite old kernels...  I guess 3.11 does *not* count :/? That'd be a

Yeah that's too old :/ 3.17 has patches to make compaction less aggressive on
THP page faults, and 3.18 prevents khugepaged from holding mmap_sem during
compaction, which could be also relevant.

> bigger machine where I could relatively quickly reenable THP to check
> whether it's still bad. I might be able to trigger it to be rebooted
> onto a newer kernel, will ask.

Thanks, that would be great, if you could do that.
I also noticed that you now support hugetlbfs. That could be also interesting
data point, if the hugetlbfs usage helped because THP code wouldn't trigger.

Vlastimil

> Greetings,
> 
> Andres Freund
>