All of lore.kernel.org
 help / color / mirror / Atom feed
From: Huang, Ying <ying.huang@intel.com>
To: lkp@lists.01.org
Subject: Re: [mm] 5c0a85fad9: unixbench.score -6.3% regression
Date: Thu, 16 Jun 2016 07:42:07 +0800	[thread overview]
Message-ID: <87bn32xbn4.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20160614133807.GA16342@bbox>

[-- Attachment #1: Type: text/plain, Size: 2145 bytes --]

Minchan Kim <minchan@kernel.org> writes:

> On Mon, Jun 13, 2016 at 05:02:15PM +0800, Huang, Ying wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 
>> > On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
>> >>
>> >> From perf profile, the time spent in page_fault and its children
>> >> functions are almost same (7.85% vs 7.81%).  So the time spent in page
>> >> fault and page table operation itself doesn't changed much.  So, you
>> >> mean CPU may be slower to load the page table entry to TLB if accessed
>> >> bit is not set?
>> >
>> > So the CPU does take a microfault internally when it needs to set the
>> > accessed/dirty bit. It's not architecturally visible, but you can see
>> > it when you do timing loops.
>> >
>> > I've timed it at over a thousand cycles on at least some CPU's, but
>> > that's still peanuts compared to a real page fault. It shouldn't be
>> > *that* noticeable, ie no way it's a 6% regression on its own.
>> 
>> I done some simple counting, and found that about 3.15e9 PTE are set to
>> old during the test after the commit.  This may interpret the user_time
>> increase as below, because these accessed bit microfault is accounted as
>> user time.
>> 
>>     387.66 .  0%      +5.4%     408.49 .  0%  unixbench.time.user_time
>> 
>> I also make a one line debug patch as below on top of the commit to set
>> the PTE to young unconditionally, which recover the regression.
>
> With this patch, meminfo.Active(file) is almost same unlike previous
> experiment?

Yes.  meminfo.Active(file) is almost same of that of the parent commit of
the first bad commit.

Best Regards,
Huang, Ying

>> 
>> modified   mm/filemap.c
>> @@ -2193,7 +2193,7 @@ repeat:
>>  		if (file->f_ra.mmap_miss > 0)
>>  			file->f_ra.mmap_miss--;
>>  		addr = address + (page->index - vmf->pgoff) * PAGE_SIZE;
>> -		do_set_pte(vma, addr, page, pte, false, false, true);
>> +		do_set_pte(vma, addr, page, pte, false, false, false);
>>  		unlock_page(page);
>>  		atomic64_inc(&old_pte_count);
>>  		goto next;
>> 
>> Best Regards,
>> Huang, Ying

WARNING: multiple messages have this Message-ID (diff)
From: "Huang\, Ying" <ying.huang@intel.com>
To: Minchan Kim <minchan@kernel.org>
Cc: "Huang\, Ying" <ying.huang@intel.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	Rik van Riel <riel@redhat.com>, "Michal Hocko" <mhocko@suse.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Vinayak Menon <vinmenon@codeaurora.org>,
	Mel Gorman <mgorman@suse.de>,
	Andrew Morton <akpm@linux-foundation.org>, LKP <lkp@01.org>
Subject: Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression
Date: Thu, 16 Jun 2016 07:42:07 +0800	[thread overview]
Message-ID: <87bn32xbn4.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <20160614133807.GA16342@bbox> (Minchan Kim's message of "Tue, 14 Jun 2016 22:38:07 +0900")

Minchan Kim <minchan@kernel.org> writes:

> On Mon, Jun 13, 2016 at 05:02:15PM +0800, Huang, Ying wrote:
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>> 
>> > On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying <ying.huang@intel.com> wrote:
>> >>
>> >> From perf profile, the time spent in page_fault and its children
>> >> functions are almost same (7.85% vs 7.81%).  So the time spent in page
>> >> fault and page table operation itself doesn't changed much.  So, you
>> >> mean CPU may be slower to load the page table entry to TLB if accessed
>> >> bit is not set?
>> >
>> > So the CPU does take a microfault internally when it needs to set the
>> > accessed/dirty bit. It's not architecturally visible, but you can see
>> > it when you do timing loops.
>> >
>> > I've timed it at over a thousand cycles on at least some CPU's, but
>> > that's still peanuts compared to a real page fault. It shouldn't be
>> > *that* noticeable, ie no way it's a 6% regression on its own.
>> 
>> I done some simple counting, and found that about 3.15e9 PTE are set to
>> old during the test after the commit.  This may interpret the user_time
>> increase as below, because these accessed bit microfault is accounted as
>> user time.
>> 
>>     387.66 .  0%      +5.4%     408.49 .  0%  unixbench.time.user_time
>> 
>> I also make a one line debug patch as below on top of the commit to set
>> the PTE to young unconditionally, which recover the regression.
>
> With this patch, meminfo.Active(file) is almost same unlike previous
> experiment?

Yes.  meminfo.Active(file) is almost same of that of the parent commit of
the first bad commit.

Best Regards,
Huang, Ying

>> 
>> modified   mm/filemap.c
>> @@ -2193,7 +2193,7 @@ repeat:
>>  		if (file->f_ra.mmap_miss > 0)
>>  			file->f_ra.mmap_miss--;
>>  		addr = address + (page->index - vmf->pgoff) * PAGE_SIZE;
>> -		do_set_pte(vma, addr, page, pte, false, false, true);
>> +		do_set_pte(vma, addr, page, pte, false, false, false);
>>  		unlock_page(page);
>>  		atomic64_inc(&old_pte_count);
>>  		goto next;
>> 
>> Best Regards,
>> Huang, Ying

  reply	other threads:[~2016-06-15 23:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-06  2:27 [mm] 5c0a85fad9: unixbench.score -6.3% regression kernel test robot
2016-06-06  2:27 ` [lkp] " kernel test robot
2016-06-06  9:51 ` Kirill A. Shutemov
2016-06-06  9:51   ` [lkp] " Kirill A. Shutemov
2016-06-08  7:21   ` Huang, Ying
2016-06-08  7:21     ` [LKP] [lkp] " Huang, Ying
2016-06-08  8:41     ` Huang, Ying
2016-06-08  8:41       ` [LKP] [lkp] " Huang, Ying
2016-06-08  8:58       ` Kirill A. Shutemov
2016-06-08  8:58         ` [LKP] [lkp] " Kirill A. Shutemov
2016-06-12  0:49         ` Huang, Ying
2016-06-12  0:49           ` [LKP] [lkp] " Huang, Ying
2016-06-12  1:02           ` Linus Torvalds
2016-06-12  1:02             ` [LKP] [lkp] " Linus Torvalds
2016-06-13  9:02             ` Huang, Ying
2016-06-13  9:02               ` [LKP] [lkp] " Huang, Ying
2016-06-14 13:38               ` Minchan Kim
2016-06-14 13:38                 ` [LKP] [lkp] " Minchan Kim
2016-06-15 23:42                 ` Huang, Ying [this message]
2016-06-15 23:42                   ` Huang, Ying
2016-06-13 12:52             ` Kirill A. Shutemov
2016-06-13 12:52               ` [LKP] [lkp] " Kirill A. Shutemov
2016-06-14  6:11               ` Linus Torvalds
2016-06-14  6:11                 ` [LKP] [lkp] " Linus Torvalds
2016-06-14  8:26                 ` Kirill A. Shutemov
2016-06-14  8:26                   ` [LKP] [lkp] " Kirill A. Shutemov
2016-06-14 16:07                   ` Rik van Riel
2016-06-14 16:07                     ` [LKP] [lkp] " Rik van Riel
2016-06-14 14:03                 ` Christian Borntraeger
2016-06-14 14:03                   ` Christian Borntraeger
2016-06-14  8:57         ` Minchan Kim
2016-06-14  8:57           ` [LKP] [lkp] " Minchan Kim
2016-06-14 14:34           ` Kirill A. Shutemov
2016-06-14 14:34             ` [LKP] [lkp] " Kirill A. Shutemov
2016-06-15 23:52             ` Huang, Ying
2016-06-15 23:52               ` [LKP] [lkp] " Huang, Ying
2016-06-16  0:13               ` Minchan Kim
2016-06-16  0:13                 ` [LKP] [lkp] " Minchan Kim
2016-06-16 22:27                 ` Huang, Ying
2016-06-16 22:27                   ` [LKP] [lkp] " Huang, Ying
2016-06-17  5:41                   ` Minchan Kim
2016-06-17  5:41                     ` [LKP] [lkp] " Minchan Kim
2016-06-17 19:26                     ` Huang, Ying
2016-06-17 19:26                       ` [LKP] [lkp] " Huang, Ying
2016-06-20  0:06                       ` Minchan Kim
2016-06-20  0:06                         ` [LKP] [lkp] " Minchan Kim

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=87bn32xbn4.fsf@yhuang-dev.intel.com \
    --to=ying.huang@intel.com \
    --cc=lkp@lists.01.org \
    /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.