From: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Aaron Lu <aaron.lu@intel.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
"'Kirill A. Shutemov'" <kirill.shutemov@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Huang Ying <ying.huang@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Jerome Marchand <jmarchan@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
Ebru Akagunduz <ebru.akagunduz@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] thp: reduce usage of huge zero page's atomic counter
Date: Tue, 30 Aug 2016 12:17:07 +0530 [thread overview]
Message-ID: <57C52BEB.8020104@linux.vnet.ibm.com> (raw)
In-Reply-To: <0342377a-26b8-16b9-5817-1964fac0e12d@intel.com>
On 08/30/2016 11:24 AM, Aaron Lu wrote:
> On 08/30/2016 12:44 PM, Anshuman Khandual wrote:
>> > On 08/30/2016 09:09 AM, Andrew Morton wrote:
>>> >> On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu <aaron.lu@intel.com> wrote:
>>> >>
>>>>>> >>>>> Case used for test on Haswell EP:
>>>>>> >>>>> usemem -n 72 --readonly -j 0x200000 100G
>>>>>> >>>>> Which spawns 72 processes and each will mmap 100G anonymous space and
>>>>>> >>>>> then do read only access to that space sequentially with a step of 2MB.
>>>>>> >>>>>
>>>>>> >>>>> perf report for base commit:
>>>>>> >>>>> 54.03% usemem [kernel.kallsyms] [k] get_huge_zero_page
>>>>>> >>>>> perf report for this commit:
>>>>>> >>>>> 0.11% usemem [kernel.kallsyms] [k] mm_get_huge_zero_page
>>>>> >>>>
>>>>> >>>> Does this mean that overall usemem runtime halved?
>>>> >>>
>>>> >>> Sorry for the confusion, the above line is extracted from perf report.
>>>> >>> It shows the percent of CPU cycles executed in a specific function.
>>>> >>>
>>>> >>> The above two perf lines are used to show get_huge_zero_page doesn't
>>>> >>> consume that much CPU cycles after applying the patch.
>>>> >>>
>>>>> >>>>
>>>>> >>>> Do we have any numbers for something which is more real-wordly?
>>>> >>>
>>>> >>> Unfortunately, no real world numbers.
>>>> >>>
>>>> >>> We think the global atomic counter could be an issue for performance
>>>> >>> so I'm trying to solve the problem.
>>> >>
>>> >> So, umm, we don't actually know if the patch is useful to anyone?
>> >
>> > On a POWER system it improves the CPU consumption of the above mentioned
>> > function a little bit. Dont think its going to improve actual throughput
>> > of the workload substantially.
>> >
>> > 0.07% usemem [kernel.vmlinux] [k] mm_get_huge_zero_page
> I guess this is the base commit? But there shouldn't be the new
> mm_get_huge_zero_page symbol before this patch. A typo perhaps?
Yeah, sorry about that.
--
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: Anshuman Khandual <khandual@linux.vnet.ibm.com>
To: Aaron Lu <aaron.lu@intel.com>,
Anshuman Khandual <khandual@linux.vnet.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: Linux Memory Management List <linux-mm@kvack.org>,
"'Kirill A. Shutemov'" <kirill.shutemov@linux.intel.com>,
Dave Hansen <dave.hansen@intel.com>,
Tim Chen <tim.c.chen@linux.intel.com>,
Huang Ying <ying.huang@intel.com>,
Vlastimil Babka <vbabka@suse.cz>,
Jerome Marchand <jmarchan@redhat.com>,
Andrea Arcangeli <aarcange@redhat.com>,
Mel Gorman <mgorman@techsingularity.net>,
Ebru Akagunduz <ebru.akagunduz@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] thp: reduce usage of huge zero page's atomic counter
Date: Tue, 30 Aug 2016 12:17:07 +0530 [thread overview]
Message-ID: <57C52BEB.8020104@linux.vnet.ibm.com> (raw)
In-Reply-To: <0342377a-26b8-16b9-5817-1964fac0e12d@intel.com>
On 08/30/2016 11:24 AM, Aaron Lu wrote:
> On 08/30/2016 12:44 PM, Anshuman Khandual wrote:
>> > On 08/30/2016 09:09 AM, Andrew Morton wrote:
>>> >> On Tue, 30 Aug 2016 11:09:15 +0800 Aaron Lu <aaron.lu@intel.com> wrote:
>>> >>
>>>>>> >>>>> Case used for test on Haswell EP:
>>>>>> >>>>> usemem -n 72 --readonly -j 0x200000 100G
>>>>>> >>>>> Which spawns 72 processes and each will mmap 100G anonymous space and
>>>>>> >>>>> then do read only access to that space sequentially with a step of 2MB.
>>>>>> >>>>>
>>>>>> >>>>> perf report for base commit:
>>>>>> >>>>> 54.03% usemem [kernel.kallsyms] [k] get_huge_zero_page
>>>>>> >>>>> perf report for this commit:
>>>>>> >>>>> 0.11% usemem [kernel.kallsyms] [k] mm_get_huge_zero_page
>>>>> >>>>
>>>>> >>>> Does this mean that overall usemem runtime halved?
>>>> >>>
>>>> >>> Sorry for the confusion, the above line is extracted from perf report.
>>>> >>> It shows the percent of CPU cycles executed in a specific function.
>>>> >>>
>>>> >>> The above two perf lines are used to show get_huge_zero_page doesn't
>>>> >>> consume that much CPU cycles after applying the patch.
>>>> >>>
>>>>> >>>>
>>>>> >>>> Do we have any numbers for something which is more real-wordly?
>>>> >>>
>>>> >>> Unfortunately, no real world numbers.
>>>> >>>
>>>> >>> We think the global atomic counter could be an issue for performance
>>>> >>> so I'm trying to solve the problem.
>>> >>
>>> >> So, umm, we don't actually know if the patch is useful to anyone?
>> >
>> > On a POWER system it improves the CPU consumption of the above mentioned
>> > function a little bit. Dont think its going to improve actual throughput
>> > of the workload substantially.
>> >
>> > 0.07% usemem [kernel.vmlinux] [k] mm_get_huge_zero_page
> I guess this is the base commit? But there shouldn't be the new
> mm_get_huge_zero_page symbol before this patch. A typo perhaps?
Yeah, sorry about that.
next prev parent reply other threads:[~2016-08-30 6:48 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-29 6:31 [PATCH] thp: reduce usage of huge zero page's atomic counter Aaron Lu
2016-08-29 6:31 ` Aaron Lu
2016-08-29 8:49 ` Anshuman Khandual
2016-08-29 8:49 ` Anshuman Khandual
2016-08-29 8:53 ` Aaron Lu
2016-08-29 8:53 ` Aaron Lu
2016-08-29 13:47 ` Anshuman Khandual
2016-08-29 13:47 ` Anshuman Khandual
2016-08-29 14:10 ` Aaron Lu
2016-08-29 14:10 ` Aaron Lu
2016-08-29 22:50 ` Andrew Morton
2016-08-29 22:50 ` Andrew Morton
2016-08-30 3:09 ` Aaron Lu
2016-08-30 3:09 ` Aaron Lu
2016-08-30 3:39 ` Andrew Morton
2016-08-30 3:39 ` Andrew Morton
2016-08-30 4:44 ` Anshuman Khandual
2016-08-30 4:44 ` Anshuman Khandual
2016-08-30 4:56 ` Andrew Morton
2016-08-30 4:56 ` Andrew Morton
2016-08-30 5:54 ` Aaron Lu
2016-08-30 5:54 ` Aaron Lu
2016-08-30 6:47 ` Anshuman Khandual [this message]
2016-08-30 6:47 ` Anshuman Khandual
2016-08-30 5:51 ` Aaron Lu
2016-08-30 5:51 ` Aaron Lu
2016-08-30 5:14 ` Anshuman Khandual
2016-08-30 5:14 ` Anshuman Khandual
2016-08-30 5:19 ` Andrew Morton
2016-08-30 5:19 ` Andrew Morton
2016-08-30 15:59 ` Sergey Senozhatsky
2016-08-30 15:59 ` Sergey Senozhatsky
2016-08-31 2:08 ` [PATCH v2] " Aaron Lu
2016-08-31 2:08 ` Aaron Lu
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=57C52BEB.8020104@linux.vnet.ibm.com \
--to=khandual@linux.vnet.ibm.com \
--cc=aarcange@redhat.com \
--cc=aaron.lu@intel.com \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@intel.com \
--cc=ebru.akagunduz@gmail.com \
--cc=jmarchan@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@techsingularity.net \
--cc=tim.c.chen@linux.intel.com \
--cc=vbabka@suse.cz \
--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.