From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752113AbaEVCtO (ORCPT ); Wed, 21 May 2014 22:49:14 -0400 Received: from mail-pb0-f46.google.com ([209.85.160.46]:56210 "EHLO mail-pb0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750965AbaEVCtN (ORCPT ); Wed, 21 May 2014 22:49:13 -0400 Date: Wed, 21 May 2014 19:49:11 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Vlastimil Babka cc: Andrew Morton , Mel Gorman , Rik van Riel , Joonsoo Kim , Greg Thelen , Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [patch -mm] mm, thp: avoid excessive compaction latency during fault fix In-Reply-To: <5371ED3F.6070505@suse.cz> Message-ID: References: <5371ED3F.6070505@suse.cz> User-Agent: Alpine 2.02 (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 Tue, 13 May 2014, Vlastimil Babka wrote: > I wonder what about a process doing e.g. mmap() with MAP_POPULATE. It seems to > me that it would get only MIGRATE_ASYNC here, right? Since gfp_mask would > include __GFP_NO_KSWAPD and it won't have PF_KTHREAD. > I think that goes against the idea that with MAP_POPULATE you say you are > willing to wait to have everything in place before you actually use the > memory. So I guess you are also willing to wait for hugepages in that > situation? > I don't understand the distinction you're making between MAP_POPULATE and simply a prefault of the anon memory. What is the difference in semantics between using MAP_POPULATE and touching a byte every page size along the range? In the latter, you'd be faulting thp with MIGRATE_ASYNC, so I don't understand how MAP_POPULATE is any different or implies any preference for hugepages. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by kanga.kvack.org (Postfix) with ESMTP id C695B6B0036 for ; Wed, 21 May 2014 22:49:13 -0400 (EDT) Received: by mail-pb0-f48.google.com with SMTP id rr13so2021527pbb.35 for ; Wed, 21 May 2014 19:49:13 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [2607:f8b0:400e:c02::229]) by mx.google.com with ESMTPS id qu8si8644356pbb.27.2014.05.21.19.49.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 May 2014 19:49:13 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id w10so1976117pde.14 for ; Wed, 21 May 2014 19:49:12 -0700 (PDT) Date: Wed, 21 May 2014 19:49:11 -0700 (PDT) From: David Rientjes Subject: Re: [patch -mm] mm, thp: avoid excessive compaction latency during fault fix In-Reply-To: <5371ED3F.6070505@suse.cz> Message-ID: References: <5371ED3F.6070505@suse.cz> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Vlastimil Babka Cc: Andrew Morton , Mel Gorman , Rik van Riel , Joonsoo Kim , Greg Thelen , Hugh Dickins , linux-kernel@vger.kernel.org, linux-mm@kvack.org On Tue, 13 May 2014, Vlastimil Babka wrote: > I wonder what about a process doing e.g. mmap() with MAP_POPULATE. It seems to > me that it would get only MIGRATE_ASYNC here, right? Since gfp_mask would > include __GFP_NO_KSWAPD and it won't have PF_KTHREAD. > I think that goes against the idea that with MAP_POPULATE you say you are > willing to wait to have everything in place before you actually use the > memory. So I guess you are also willing to wait for hugepages in that > situation? > I don't understand the distinction you're making between MAP_POPULATE and simply a prefault of the anon memory. What is the difference in semantics between using MAP_POPULATE and touching a byte every page size along the range? In the latter, you'd be faulting thp with MIGRATE_ASYNC, so I don't understand how MAP_POPULATE is any different or implies any preference for hugepages. -- 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