From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751828AbcF2VC7 (ORCPT ); Wed, 29 Jun 2016 17:02:59 -0400 Received: from mail-pf0-f182.google.com ([209.85.192.182]:36437 "EHLO mail-pf0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751450AbcF2VC5 (ORCPT ); Wed, 29 Jun 2016 17:02:57 -0400 Date: Wed, 29 Jun 2016 13:55:55 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Vlastimil Babka cc: Andrew Morton , Joonsoo Kim , Mel Gorman , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [patch] mm, compaction: make sure freeing scanner isn't persistently expensive In-Reply-To: <6685fe19-753d-7d76-aced-3bb071d7c81d@suse.cz> Message-ID: References: <6685fe19-753d-7d76-aced-3bb071d7c81d@suse.cz> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 29 Jun 2016, Vlastimil Babka wrote: > On 06/29/2016 03:39 AM, David Rientjes wrote: > > It's possible that the freeing scanner can be consistently expensive if > > memory is well compacted toward the end of the zone with few free pages > > available in that area. > > > > If all zone memory is synchronously compacted, say with > > /proc/sys/vm/compact_memory, and thp is faulted, it is possible to > > iterate a massive amount of memory even with the per-zone cached free > > position. > > > > For example, after compacting all memory and faulting thp for heap, it > > was observed that compact_free_scanned increased as much as 892518911 4KB > > pages while compact_stall only increased by 171. The freeing scanner > > iterated ~20GB of memory for each compaction stall. > > > > To address this, if too much memory is spanned on the freeing scanner's > > freelist when releasing back to the system, return the low pfn rather than > > the high pfn. It's declared that the freeing scanner will become too > > expensive if the high pfn is used, so use the low pfn instead. > > > > The amount of memory declared as too expensive to iterate is subjectively > > chosen at COMPACT_CLUSTER_MAX << PAGE_SHIFT, which is 512MB with 4KB > > pages. > > > > Signed-off-by: David Rientjes > > Hmm, I don't know. Seems it only works around one corner case of a larger > issue. The cost for the scanning was already paid, the patch prevents it from > being paid again, but only until the scanners are reset. > The only point of the per-zone cached pfn positions is to avoid doing the same work again unnecessarily. Having the last 16GB of memory at the end of a zone being completely unfree is the same as a single page in the last pageblock free. The number of PageBuddy pages in that amount of memory can be irrelevant up to COMPACT_CLUSTER_MAX. We simply can't afford to scan 16GB of memory looking for free pages. > Note also that THP's no longer do direct compaction by default in recent > kernels. > > To fully solve the freepage scanning issue, we should probably pick and finish > one of the proposed reworks from Joonsoo or myself, or the approach that > replaces free scanner with direct freelist allocations. > Feel free to post the patches, but I believe this simple change makes release_freepages() exceedingly better and can better target memory for the freeing scanner.