From: "Kirill A. Shutemov" <firstname.lastname@example.org> To: Linus Torvalds <email@example.com>, Rik van Riel <firstname.lastname@example.org>, Mel Gorman <email@example.com> Cc: "Kirill A. Shutemov" <firstname.lastname@example.org>, "Huang, Ying" <email@example.com>, Michal Hocko <firstname.lastname@example.org>, LKML <email@example.com>, Michal Hocko <firstname.lastname@example.org>, Minchan Kim <email@example.com>, Vinayak Menon <firstname.lastname@example.org>, Andrew Morton <email@example.com>, LKP <firstname.lastname@example.org>, Dave Hansen <email@example.com>, Vladimir Davydov <firstname.lastname@example.org> Subject: Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression Date: Tue, 14 Jun 2016 11:26:13 +0300 [thread overview] Message-ID: <20160614082613.GA1066@node.shutemov.name> (raw) In-Reply-To: <CA+55aFx2TdqHW5VvirF-fAe4rRtSKK6BH06LyN4Ma3Q7ifJkxA@mail.gmail.com> On Mon, Jun 13, 2016 at 11:11:05PM -0700, Linus Torvalds wrote: > On Mon, Jun 13, 2016 at 5:52 AM, Kirill A. Shutemov > <email@example.com> wrote: > > On Sat, Jun 11, 2016 at 06:02:57PM -0700, Linus Torvalds wrote: > >> > >> 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. > > > > Looks like setting accessed bit is the problem. > > Ok. I've definitely seen it as an issue, but never to the point of > several percent on a real benchmark that wasn't explicitly testing > that cost. > > I reported the excessive dirty/accessed bit cost to Intel back in the > P4 days, but it's apparently not been high enough for anybody to care. > > > We spend 36% more time in page walk only, about 1% of total userspace time. > > Combining this with page walk footprint on caches, I guess we can get to > > this 3.5% score difference I see. > > > > I'm not sure if there's anything we can do to solve the issue without > > screwing relacim logic again. :( > > I think we should say "screw the reclaim logic" for now, and revert > commit 5c0a85fad949 for now. Okay. I'll prepare the patch. > Considering how much trouble the accessed bit is on some other > architectures too, I wonder if we should strive to simply not care > about it, and always leaving it set. And then rely entirely on just > unmapping the pages and making the "we took a page fault after > unmapping" be the real activity tester. > > So get rid of the "if the page is young, mark it old but leave it in > the page tables" logic entirely. When we unmap a page, it will always > either be in the swap cache or the page cache anyway, so faulting it > in again should be just a minor fault with no actual IO happening. > > That might be less of an impact in the end - yes, the unmap and > re-fault is much more expensive, but it presumably happens to much > fewer pages. > > What do you think? Well, we cannot do this for anonymous memory. No swap -- no swap cache, if I read code correctly. I guess it's doable for file mappings. Although I would expect regressions in other benchmarks. IIUC, it would require page unmapping to propogate page to active list, which is suboptimal. And implications for page_idle is not clear to me. Rik, Mel, any comments? -- Kirill A. Shutemov
next prev parent reply other threads:[~2016-06-14 8:26 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-06 2:27 kernel test robot 2016-06-06 9:51 ` Kirill A. Shutemov 2016-06-08 7:21 ` [LKP] " Huang, Ying 2016-06-08 8:41 ` Huang, Ying 2016-06-08 8:58 ` Kirill A. Shutemov 2016-06-12 0:49 ` Huang, Ying 2016-06-12 1:02 ` Linus Torvalds 2016-06-13 9:02 ` Huang, Ying 2016-06-14 13:38 ` Minchan Kim 2016-06-15 23:42 ` Huang, Ying 2016-06-13 12:52 ` Kirill A. Shutemov 2016-06-14 6:11 ` Linus Torvalds 2016-06-14 8:26 ` Kirill A. Shutemov [this message] 2016-06-14 16:07 ` Rik van Riel 2016-06-14 14:03 ` Christian Borntraeger 2016-06-14 8:57 ` Minchan Kim 2016-06-14 14:34 ` Kirill A. Shutemov 2016-06-15 23:52 ` Huang, Ying 2016-06-16 0:13 ` Minchan Kim 2016-06-16 22:27 ` Huang, Ying 2016-06-17 5:41 ` Minchan Kim 2016-06-17 19:26 ` Huang, Ying 2016-06-20 0:06 ` 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=20160614082613.GA1066@node.shutemov.name \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [LKP] [lkp] [mm] 5c0a85fad9: unixbench.score -6.3% regression' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).