From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932286AbaEGJjk (ORCPT ); Wed, 7 May 2014 05:39:40 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56816 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751652AbaEGJjj (ORCPT ); Wed, 7 May 2014 05:39:39 -0400 Date: Wed, 7 May 2014 10:39:35 +0100 From: Mel Gorman To: David Rientjes Cc: Andrew Morton , Rik van Riel , Vlastimil Babka , Joonsoo Kim , Greg Thelen , Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch v3 5/6] mm, thp: avoid excessive compaction latency during fault Message-ID: <20140507093935.GE23991@suse.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 06, 2014 at 07:22:50PM -0700, David Rientjes wrote: > Synchronous memory compaction can be very expensive: it can iterate an enormous > amount of memory without aborting, constantly rescheduling, waiting on page > locks and lru_lock, etc, if a pageblock cannot be defragmented. > > Unfortunately, it's too expensive for transparent hugepage page faults and > it's much better to simply fallback to pages. On 128GB machines, we find that > synchronous memory compaction can take O(seconds) for a single thp fault. > > Now that async compaction remembers where it left off without strictly relying > on sync compaction, this makes thp allocations best-effort without causing > egregious latency during fault. We still need to retry async compaction after > reclaim, but this won't stall for seconds. > > Signed-off-by: David Rientjes Acked-by: Mel Gorman -- Mel Gorman SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by kanga.kvack.org (Postfix) with ESMTP id 9B2BE6B0035 for ; Wed, 7 May 2014 05:39:40 -0400 (EDT) Received: by mail-ee0-f54.google.com with SMTP id b57so516037eek.41 for ; Wed, 07 May 2014 02:39:40 -0700 (PDT) Received: from mx2.suse.de (cantor2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id n7si15818689eeu.19.2014.05.07.02.39.38 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 07 May 2014 02:39:39 -0700 (PDT) Date: Wed, 7 May 2014 10:39:35 +0100 From: Mel Gorman Subject: Re: [patch v3 5/6] mm, thp: avoid excessive compaction latency during fault Message-ID: <20140507093935.GE23991@suse.de> References: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: David Rientjes Cc: Andrew Morton , Rik van Riel , Vlastimil Babka , Joonsoo Kim , Greg Thelen , Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org On Tue, May 06, 2014 at 07:22:50PM -0700, David Rientjes wrote: > Synchronous memory compaction can be very expensive: it can iterate an enormous > amount of memory without aborting, constantly rescheduling, waiting on page > locks and lru_lock, etc, if a pageblock cannot be defragmented. > > Unfortunately, it's too expensive for transparent hugepage page faults and > it's much better to simply fallback to pages. On 128GB machines, we find that > synchronous memory compaction can take O(seconds) for a single thp fault. > > Now that async compaction remembers where it left off without strictly relying > on sync compaction, this makes thp allocations best-effort without causing > egregious latency during fault. We still need to retry async compaction after > reclaim, but this won't stall for seconds. > > Signed-off-by: David Rientjes Acked-by: Mel Gorman -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org