From: John Hubbard <jhubbard@nvidia.com>
To: "Huang, Ying" <ying.huang@intel.com>,
David Rientjes <rientjes@google.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Andi Kleen <ak@linux.intel.com>,
Dave Hansen <dave.hansen@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: Thu, 23 Mar 2017 21:27:47 -0700 [thread overview]
Message-ID: <f17cb7e4-4d47-4aed-6fdb-cda5c5d47fa4@nvidia.com> (raw)
In-Reply-To: <8737e3z992.fsf@yhuang-dev.intel.com>
On 03/23/2017 07:41 PM, Huang, Ying wrote:
> David Rientjes <rientjes@google.com> writes:
>
>> On Mon, 20 Mar 2017, Huang, Ying wrote:
>>
>>> From: Huang Ying <ying.huang@intel.com>
>>>
>>> Now vzalloc() is used in swap code to allocate various data
>>> structures, such as swap cache, swap slots cache, cluster info, etc.
>>> Because the size may be too large on some system, so that normal
>>> kzalloc() may fail. But using kzalloc() has some advantages, for
>>> example, less memory fragmentation, less TLB pressure, etc. So change
>>> the data structure allocation in swap code to use kvzalloc() which
>>> will try kzalloc() firstly, and fallback to vzalloc() if kzalloc()
>>> failed.
>>>
>>
>> As questioned in -v1 of this patch, what is the benefit of directly
>> compacting and reclaiming memory for high-order pages by first preferring
>> kmalloc() if this does not require contiguous memory?
>
> The memory allocation here is only for swap on time, not for swap out/in
> time. The performance of swap on is not considered critical. But if
> the kmalloc() is used instead of the vmalloc(), the swap out/in
> performance could be improved (marginally). More importantly, the
> interference for the other activity on the system could be reduced, For
> example, less memory fragmentation, less TLB usage of swap subsystem,
> etc.
Hi Ying,
I'm a little surprised to see vmalloc calls replaced with kmalloc-then-vmalloc calls, because that
actually makes fragmentation worse (contrary to the above claim). That's because you will consume
contiguous memory (even though you don't need it to be contiguous), whereas before, you would have
been able to get by with page-at-a-time for vmalloc.
So, things like THP will find fewer contiguous chunks, as a result of patches such as this.
--
thanks,
john h
>
> Best Regards,
> Huang, Ying
>
> --
> 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>
next prev parent reply other threads:[~2017-03-24 4:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
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 21:32 ` [PATCH -v2 1/2] mm, swap: Use kvzalloc to allocate some swap data structure David Rientjes
2017-03-24 2:41 ` Huang, Ying
2017-03-24 4:27 ` John Hubbard [this message]
2017-03-24 4:52 ` Huang, Ying
2017-03-24 6:48 ` John Hubbard
2017-03-24 7:16 ` Huang, Ying
2017-03-24 7:33 ` John Hubbard
2017-03-24 13:56 ` Dave Hansen
2017-03-24 16:52 ` Tim Chen
2017-03-24 18:15 ` John Hubbard
2017-03-30 16:31 ` Michal Hocko
2017-04-01 4:47 ` Huang, Ying
2017-04-03 8:15 ` Michal Hocko
2017-04-05 0:49 ` Huang, Ying
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=f17cb7e4-4d47-4aed-6fdb-cda5c5d47fa4@nvidia.com \
--to=jhubbard@nvidia.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox