All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlastimil Babka <vbabka@suse.cz>
To: Dave Hansen <dave.hansen@linux.intel.com>,
	John Hubbard <jhubbard@nvidia.com>,
	"Huang, Ying" <ying.huang@intel.com>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@linux.intel.com>, Shaohua Li <shli@kernel.org>,
	Rik van Riel <riel@redhat.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Michal Hocko <mhocko@suse.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Aaron Lu <aaron.lu@intel.com>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure
Date: Wed, 5 Apr 2017 15:43:49 +0200	[thread overview]
Message-ID: <d7fd1c69-2e0e-39ec-dfd8-16269f0cb898@suse.cz> (raw)
In-Reply-To: <e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com>

On 03/24/2017 02:56 PM, Dave Hansen wrote:
> On 03/24/2017 12:33 AM, John Hubbard wrote:
>> There might be some additional information you are using to come up with
>> that conclusion, that is not obvious to me. Any thoughts there? These
>> calls use the same underlying page allocator (and I thought that both
>> were subject to the same constraints on defragmentation, as a result of
>> that). So I am not seeing any way that kmalloc could possibly be a
>> less-fragmenting call than vmalloc.
> 
> You guys are having quite a discussion over a very small point.

Sorry, I know I'm too late for this discussion, just wanted to clarify a
bit.

> But, Ying is right.
> 
> Let's say we have a two-page data structure.  vmalloc() takes two
> effectively random order-0 pages, probably from two different 2M pages
> and pins them.  That "kills" two 2M pages.
> 
> kmalloc(), allocating two *contiguous* pages, is very unlikely to cross
> a 2M boundary (it theoretically could).

If by "theoretically" you mean we switch kmalloc() from a buddy
allocator to something else, then yes. Otherwise, in the buddy
allocator, it cannot cross the 2M boundary by design.

> That means it will only "kill"
> the possibility of a single 2M page.  More 2M pages == less fragmentation.

IMHO John is right that kmalloc() will reduce the number of high-order
pages *in the short term*. But in the long term, vmalloc() will hurt us
more due to the scattering of unmovable pages as you describe. As this
is AFAIU a long-term allocation, kmalloc() should be preferred.

Vlastimil

> --
> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Dave Hansen <dave.hansen@linux.intel.com>,
	John Hubbard <jhubbard@nvidia.com>,
	"Huang, Ying" <ying.huang@intel.com>
Cc: David Rientjes <rientjes@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Andi Kleen <ak@linux.intel.com>, Shaohua Li <shli@kernel.org>,
	Rik van Riel <riel@redhat.com>,
	Tim Chen <tim.c.chen@linux.intel.com>,
	Michal Hocko <mhocko@suse.com>,
	Mel Gorman <mgorman@techsingularity.net>,
	Aaron Lu <aaron.lu@intel.com>,
	Gerald Schaefer <gerald.schaefer@de.ibm.com>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Hugh Dickins <hughd@google.com>, Ingo Molnar <mingo@kernel.org>,
	Vegard Nossum <vegard.nossum@oracle.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure
Date: Wed, 5 Apr 2017 15:43:49 +0200	[thread overview]
Message-ID: <d7fd1c69-2e0e-39ec-dfd8-16269f0cb898@suse.cz> (raw)
In-Reply-To: <e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com>

On 03/24/2017 02:56 PM, Dave Hansen wrote:
> On 03/24/2017 12:33 AM, John Hubbard wrote:
>> There might be some additional information you are using to come up with
>> that conclusion, that is not obvious to me. Any thoughts there? These
>> calls use the same underlying page allocator (and I thought that both
>> were subject to the same constraints on defragmentation, as a result of
>> that). So I am not seeing any way that kmalloc could possibly be a
>> less-fragmenting call than vmalloc.
> 
> You guys are having quite a discussion over a very small point.

Sorry, I know I'm too late for this discussion, just wanted to clarify a
bit.

> But, Ying is right.
> 
> Let's say we have a two-page data structure.  vmalloc() takes two
> effectively random order-0 pages, probably from two different 2M pages
> and pins them.  That "kills" two 2M pages.
> 
> kmalloc(), allocating two *contiguous* pages, is very unlikely to cross
> a 2M boundary (it theoretically could).

If by "theoretically" you mean we switch kmalloc() from a buddy
allocator to something else, then yes. Otherwise, in the buddy
allocator, it cannot cross the 2M boundary by design.

> That means it will only "kill"
> the possibility of a single 2M page.  More 2M pages == less fragmentation.

IMHO John is right that kmalloc() will reduce the number of high-order
pages *in the short term*. But in the long term, vmalloc() will hurt us
more due to the scattering of unmovable pages as you describe. As this
is AFAIU a long-term allocation, kmalloc() should be preferred.

Vlastimil

> --
> 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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
> 

--
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: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  parent reply	other threads:[~2017-04-05 13:44 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-20  8:47 [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure Huang, Ying
2017-03-20  8:47 ` Huang, Ying
2017-03-20  8:47 ` [PATCH -v2 2/2] mm, swap: Sort swap entries before free Huang, Ying
2017-03-20  8:47   ` Huang, Ying
2017-03-20 21:32 ` [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure David Rientjes
2017-03-20 21:32   ` David Rientjes
2017-03-24  2:41   ` Huang, Ying
2017-03-24  2:41     ` Huang, Ying
2017-03-24  4:27     ` John Hubbard
2017-03-24  4:27       ` John Hubbard
2017-03-24  4:52       ` Huang, Ying
2017-03-24  4:52         ` Huang, Ying
2017-03-24  6:48         ` John Hubbard
2017-03-24  6:48           ` John Hubbard
2017-03-24  7:16           ` Huang, Ying
2017-03-24  7:16             ` Huang, Ying
2017-03-24  7:33             ` John Hubbard
2017-03-24  7:33               ` John Hubbard
2017-03-24 13:56               ` Dave Hansen
2017-03-24 13:56                 ` Dave Hansen
2017-03-24 16:52                 ` Tim Chen
2017-03-24 16:52                   ` Tim Chen
2017-03-24 18:15                   ` John Hubbard
2017-03-24 18:15                     ` John Hubbard
2017-03-30 16:31                 ` Michal Hocko
2017-03-30 16:31                   ` Michal Hocko
2017-04-01  4:47                   ` Huang, Ying
2017-04-01  4:47                     ` Huang, Ying
2017-04-03  8:15                     ` Michal Hocko
2017-04-03  8:15                       ` Michal Hocko
2017-04-05  0:49                       ` Huang, Ying
2017-04-05  0:49                         ` Huang, Ying
2017-04-05 13:43                 ` Vlastimil Babka [this message]
2017-04-05 13:43                   ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d7fd1c69-2e0e-39ec-dfd8-16269f0cb898@suse.cz \
    --to=vbabka@suse.cz \
    --cc=aaron.lu@intel.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=hughd@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mingo@kernel.org \
    --cc=riel@redhat.com \
    --cc=rientjes@google.com \
    --cc=shli@kernel.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vegard.nossum@oracle.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.