From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933119AbcFOXmP (ORCPT ); Wed, 15 Jun 2016 19:42:15 -0400 Received: from mga02.intel.com ([134.134.136.20]:9616 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932570AbcFOXmL (ORCPT ); Wed, 15 Jun 2016 19:42:11 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,478,1459839600"; d="scan'208";a="122679673" From: "Huang\, Ying" To: Minchan Kim Cc: "Huang\, Ying" , Linus Torvalds , "Kirill A. Shutemov" , Rik van Riel , "Michal Hocko" , LKML , Michal Hocko , Vinayak Menon , Mel Gorman , Andrew Morton , LKP Subject: Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression References: <20160606022724.GA26227@yexl-desktop> <20160606095136.GA79951@black.fi.intel.com> <87a8iw5enf.fsf@yhuang-dev.intel.com> <8760tk5aym.fsf@yhuang-dev.intel.com> <20160608085811.GB12655@black.fi.intel.com> <87porn44fm.fsf@yhuang-dev.intel.com> <87bn35zcko.fsf@yhuang-dev.intel.com> <20160614133807.GA16342@bbox> Date: Thu, 16 Jun 2016 07:42:07 +0800 In-Reply-To: <20160614133807.GA16342@bbox> (Minchan Kim's message of "Tue, 14 Jun 2016 22:38:07 +0900") Message-ID: <87bn32xbn4.fsf@yhuang-dev.intel.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Minchan Kim writes: > On Mon, Jun 13, 2016 at 05:02:15PM +0800, Huang, Ying wrote: >> Linus Torvalds writes: >> >> > On Sat, Jun 11, 2016 at 5:49 PM, Huang, Ying 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