Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752790AbbBXLqI (ORCPT ); Tue, 24 Feb 2015 06:46:08 -0500 Received: from mx1.redhat.com ([209.132.183.28]:42864 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752392AbbBXLqH (ORCPT ); Tue, 24 Feb 2015 06:46:07 -0500 Date: Tue, 24 Feb 2015 12:45:03 +0100 From: Andrea Arcangeli To: Vlastimil Babka Cc: Andrew Morton , Davidlohr Bueso , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Hugh Dickins , "Kirill A. Shutemov" , Rik van Riel , Mel Gorman , Michal Hocko , Ebru Akagunduz , Alex Thorlton , David Rientjes , Peter Zijlstra , Ingo Molnar Subject: Re: [RFC 0/6] the big khugepaged redesign Message-ID: <20150224114503.GH5542@redhat.com> 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> <20150224112412.GG5542@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150224112412.GG5542@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1956 Lines: 35 On Tue, Feb 24, 2015 at 12:24:12PM +0100, Andrea Arcangeli wrote: > I would advise not to make changes for app that are already the > biggest users ever of hugetlbfs (like Oracle). Those already are > optimized by other means. THP target are apps that have several Before somebody risks to misunderstand perhaps I should clarify further: what I meant is that if the khugepaged boost helps Oracle or other heavy users of hugetlbfs, but it _hurts_ everything else as I'd guess, I'd advise against it. Because if an app can deal with hugetlbfs it's much simpler to optimize by other means and it's not the primary target of THP so the priority for THP default behavior should be biased towards those apps that can't easily fit into hugetlbfs and numa hard pins static placement models. Of course it'd be perfectly fine to make THP changes that helps even the biggest hugetlbfs users out there, as long as these changes don't hurt all other normal use cases (where THP is always guaranteed to provide a significant performance boost if enabled). Chances are the benchmarks are also comparing "hugetlbfs+THP" vs "hugetlbfs" without THP, and not "nothing" vs "THP". Clearly I'd like to optimize for all apps including the biggest hugetlbfs users, and this is why I'd like to optimize redis as well, considering it's simple enough to do it with just one madvise to change the behavior of COW faults and it'd be guaranteed not to hurt any other common usage. If we were to instead change the default behavior of COW faults we'd need first to collect data for a variety of apps and personally I doubt such a change would be a good universal tradeoff, while it's a fine change for a behavioral change through madvise. -- 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/