Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1947390AbbGaVRZ (ORCPT ); Fri, 31 Jul 2015 17:17:25 -0400 Received: from mail-pd0-f175.google.com ([209.85.192.175]:36425 "EHLO mail-pd0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753429AbbGaVRU (ORCPT ); Fri, 31 Jul 2015 17:17:20 -0400 Date: Fri, 31 Jul 2015 14:17:18 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Mel Gorman cc: Vlastimil Babka , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Hugh Dickins , Andrea Arcangeli , "Kirill A. Shutemov" , Rik van Riel , Joonsoo Kim Subject: Re: [RFC 1/4] mm, compaction: introduce kcompactd In-Reply-To: <20150730105732.GJ19352@techsingularity.net> Message-ID: References: <1435826795-13777-1-git-send-email-vbabka@suse.cz> <1435826795-13777-2-git-send-email-vbabka@suse.cz> <20150730105732.GJ19352@techsingularity.net> 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 Content-Length: 1658 Lines: 32 On Thu, 30 Jul 2015, Mel Gorman wrote: > There will be different opinions on periodic compaction but to be honest, > periodic compaction also could be implemented from userspace using the > compact_node sysfs files. The risk with periodic compaction is that it > can cause stalls in applications that do not care if they fault the pages > being migrated. This may happen even though there are zero requirements > for high-order pages from anybody. > When thp is enabled, I think there is always a non-zero requirement for high-order pages. That's why we've shown an increase of 1.4% in cpu utilization over all our machines by doing periodic memory compaction. It's essential when thp is enabled and no amount of background compaction kicked off with a trigger similar to kswapd (which I have agreed with in this thread) is going to assist when a very large process is exec'd. That's why my proposal was for background compaction through kcompactd kicked off in the allocator slowpath and for periodic compaction on, at the minimum, thp configurations to keep fragmentation low. Dave Chinner seems to also have a usecase absent thp for high-order page cache allocation. I think it would depend on how aggressive you are proposing background compaction to be, whether it will ever be MIGRATE_SYNC over all memory, or whether it will only terminate when a fragmentation index meets a threshold. -- 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/