[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87lhjouyqt.fsf@tassilo.jf.intel.com>
Date: Mon, 23 Feb 2015 13:03:22 -0800
From: Andi Kleen <andi@...stfloor.org>
To: Vlastimil Babka <vbabka@...e.cz>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Andrew Morton <akpm@...ux-foundation.org>,
Hugh Dickins <hughd@...gle.com>,
Andrea Arcangeli <aarcange@...hat.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Rik van Riel <riel@...hat.com>, Mel Gorman <mgorman@...e.de>,
Michal Hocko <mhocko@...e.cz>,
Ebru Akagunduz <ebru.akagunduz@...il.com>,
Alex Thorlton <athorlton@....com>,
David Rientjes <rientjes@...gle.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [RFC 0/6] the big khugepaged redesign
Vlastimil Babka <vbabka@...e.cz> writes:
> This has been already discussed as a good
> idea and a RFC has been posted by Alex Thorlton last October [5].
In my opinion it's a very bad idea. It heavily penalizes the single
threaded application case, which is quite important. And it
would likely lead to even larger latencies on the application
base, even for the multithreaded case, as there is no good way
anymore to hide blocking latencies in the process.
The current single thead khugepaged has various issues, but this would
just make it much worse.
IMHO it's useless to do much here without a lot of data first
to identify the actual problems. Doing things first without analysis
first seems totally backwards.
-Andi
--
ak@...ux.intel.com -- Speaking for myself only
--
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/
Powered by blists - more mailing lists