All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Hansen <dave.hansen@linux.intel.com>
To: 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: Fri, 24 Mar 2017 06:56:10 -0700	[thread overview]
Message-ID: <e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com> (raw)
In-Reply-To: <624b8e59-34e5-3538-0a93-d33d9e4ac555@nvidia.com>

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.

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).  That means it will only "kill"
the possibility of a single 2M page.  More 2M pages == less fragmentation.

WARNING: multiple messages have this Message-ID (diff)
From: Dave Hansen <dave.hansen@linux.intel.com>
To: 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: Fri, 24 Mar 2017 06:56:10 -0700	[thread overview]
Message-ID: <e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com> (raw)
In-Reply-To: <624b8e59-34e5-3538-0a93-d33d9e4ac555@nvidia.com>

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.

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).  That means it will only "kill"
the possibility of a single 2M page.  More 2M pages == less fragmentation.

--
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>

  reply	other threads:[~2017-03-24 13:57 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 [this message]
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
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=e79064f1-8594-bef2-fbd8-1579afb4aac3@linux.intel.com \
    --to=dave.hansen@linux.intel.com \
    --cc=aaron.lu@intel.com \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --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.