From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752612AbcFNNiH (ORCPT ); Tue, 14 Jun 2016 09:38:07 -0400 Received: from LGEAMRELO13.lge.com ([156.147.23.53]:42423 "EHLO lgeamrelo13.lge.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752053AbcFNNiG (ORCPT ); Tue, 14 Jun 2016 09:38:06 -0400 X-Original-SENDERIP: 156.147.1.121 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 165.244.98.150 X-Original-MAILFROM: minchan@kernel.org X-Original-SENDERIP: 10.177.223.161 X-Original-MAILFROM: minchan@kernel.org Date: Tue, 14 Jun 2016 22:38:07 +0900 From: Minchan Kim To: "Huang, Ying" CC: 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 Message-ID: <20160614133807.GA16342@bbox> 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> MIME-Version: 1.0 In-Reply-To: <87bn35zcko.fsf@yhuang-dev.intel.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-MIMETrack: Itemize by SMTP Server on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/14 22:38:01, Serialize by Router on LGEKRMHUB06/LGE/LG Group(Release 8.5.3FP6|November 21, 2013) at 2016/06/14 22:38:01, Serialize complete at 2016/06/14 22:38:01 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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? > > 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