Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753101AbcD1IxW (ORCPT ); Thu, 28 Apr 2016 04:53:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:60615 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751912AbcD1IxU (ORCPT ); Thu, 28 Apr 2016 04:53:20 -0400 Subject: Re: [PATCH 09/14] mm: use compaction feedback for thp backoff conditions To: Michal Hocko , Andrew Morton References: <1461181647-8039-1-git-send-email-mhocko@kernel.org> <1461181647-8039-10-git-send-email-mhocko@kernel.org> Cc: Linus Torvalds , Johannes Weiner , Mel Gorman , David Rientjes , Tetsuo Handa , Joonsoo Kim , Hillf Danton , linux-mm@kvack.org, LKML , Michal Hocko From: Vlastimil Babka Message-ID: <5721CF7E.9020106@suse.cz> Date: Thu, 28 Apr 2016 10:53:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1461181647-8039-10-git-send-email-mhocko@kernel.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1800 Lines: 36 On 04/20/2016 09:47 PM, Michal Hocko wrote: > From: Michal Hocko > > THP requests skip the direct reclaim if the compaction is either > deferred or contended to reduce stalls which wouldn't help the > allocation success anyway. These checks are ignoring other potential > feedback modes which we have available now. > > It clearly doesn't make much sense to go and reclaim few pages if the > previous compaction has failed. > > We can also simplify the check by using compaction_withdrawn which > checks for both COMPACT_CONTENDED and COMPACT_DEFERRED. This check > is however covering more reasons why the compaction was withdrawn. > None of them should be a problem for the THP case though. > > It is safe to back of if we see COMPACT_SKIPPED because that means > that compaction_suitable failed and a single round of the reclaim is > unlikely to make any difference here. We would have to be close to > the low watermark to reclaim enough and even then there is no guarantee > that the compaction would make any progress while the direct reclaim > would have caused the stall. > > COMPACT_PARTIAL_SKIPPED is slightly different because that means that we > have only seen a part of the zone so a retry would make some sense. But > it would be a compaction retry not a reclaim retry to perform. We are > not doing that and that might indeed lead to situations where THP fails > but this should happen only rarely and it would be really hard to > measure. > > Signed-off-by: Michal Hocko THP's don't compact by default in page fault path anymore, so we don't need to restrict them even more. And hopefully we'll replace the is_thp_gfp_mask() hack with something better soon, so this might be just extra code churn. But I don't feel strongly enough to nack it.