From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1422717AbcFMJCV (ORCPT ); Mon, 13 Jun 2016 05:02:21 -0400 Received: from mga14.intel.com ([192.55.52.115]:38784 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933300AbcFMJCT (ORCPT ); Mon, 13 Jun 2016 05:02:19 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,466,1459839600"; d="scan'208";a="826875620" From: "Huang\, Ying" To: Linus Torvalds Cc: "Huang\, Ying" , "Kirill A. Shutemov" , Rik van Riel , Michal Hocko , LKML , Michal Hocko , Minchan Kim , 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> Date: Mon, 13 Jun 2016 17:02:15 +0800 In-Reply-To: (Linus Torvalds's message of "Sat, 11 Jun 2016 18:02:57 -0700") Message-ID: <87bn35zcko.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 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. 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