From: Michal Hocko <mhocko@kernel.org>
To: Vinayak Menon <vinmenon@codeaurora.org>
Cc: linux-mm@kvack.org, kirill.shutemov@linux.intel.com,
akpm@linux-foundation.org, minchan@kernel.org,
catalin.marinas@arm.com, will.deacon@arm.com,
ying.huang@intel.com, riel@redhat.com,
dave.hansen@linux.intel.com, mgorman@suse.de,
torvalds@linux-foundation.org, jack@suse.cz
Subject: Re: [PATCH v3] mm: make faultaround produce old ptes
Date: Tue, 23 Jan 2018 17:05:09 +0100 [thread overview]
Message-ID: <20180123160509.GT1526@dhcp22.suse.cz> (raw)
In-Reply-To: <d5a87398-a51f-69fb-222b-694328be7387@codeaurora.org>
On Tue 23-01-18 21:08:36, Vinayak Menon wrote:
>
>
> On 1/23/2018 8:25 PM, Michal Hocko wrote:
> > [Please cc linux-api when proposing user interface]
> >
> > On Mon 22-01-18 11:10:14, Vinayak Menon wrote:
> >> Based on Kirill's patch [1].
> >>
> >> Currently, faultaround code produces young pte. This can screw up
> >> vmscan behaviour[2], as it makes vmscan think that these pages are hot
> >> and not push them out on first round.
> >>
> >> During sparse file access faultaround gets more pages mapped and all of
> >> them are young. Under memory pressure, this makes vmscan swap out anon
> >> pages instead, or to drop other page cache pages which otherwise stay
> >> resident.
> >>
> >> Modify faultaround to produce old ptes if sysctl 'want_old_faultaround_pte'
> >> is set, so they can easily be reclaimed under memory pressure.
> >>
> >> This can to some extend defeat the purpose of faultaround on machines
> >> without hardware accessed bit as it will not help us with reducing the
> >> number of minor page faults.
> > So we just want to add a knob to cripple the feature? Isn't it better to
> > simply disable it than to have two distinct implementation which is
> > rather non-intuitive and I would bet that most users will be clueless
> > about how to set it or when to touch it at all. So we will end up with
> > random cargo cult hints all over internet giving you your performance
> > back...
>
>
> If you are talking about non-HW access bit systems, then yes it would be better to disable faultaround
> when want_old_faultaround_pte is set to 1, like MInchan did here https://patchwork.kernel.org/patch/9115901/
> I can submit a patch for that.
>
> > I really dislike this new interface. If the fault around doesn't work
> > for you then disable it.
>
>
> Faultaround works well for me on systems with HW access bit. But
> the benefit is reduced because of making the faultaround ptes young
> [2]. Ideally they should be old as they are speculatively mapped and
> not really accessed. But because of issues on certain architectures
> they need to be made young[3][4]. This patch is trying to help the
> other architectures which can tolerate old ptes, by fixing the vmscan
> behaviour. And this is not a theoretical problem that I am trying to
> fix. We have really seen the benefit of faultaround on arm mobile
> targets, but the problem is the vmscan behaviour due to the young
> pte workaround. And this patch helps in fixing that. Do you think
> something more needs to be added in the documentation to make things
> more clear on the flag usage ?
No, I would either prefer auto-tuning or document that fault around
can lead to this behavior and recommend to disable it rather than add a
new knob.
--
Michal Hocko
SUSE Labs
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2018-01-23 16:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-22 5:40 Vinayak Menon
2018-01-23 14:55 ` Michal Hocko
2018-01-23 14:55 ` Michal Hocko
2018-01-23 15:38 ` Vinayak Menon
2018-01-23 16:05 ` Michal Hocko [this message]
2018-01-24 9:05 ` Vinayak Menon
2018-01-24 9:38 ` Michal Hocko
2018-01-24 10:43 ` Vinayak Menon
2018-01-24 11:11 ` Michal Hocko
2018-01-24 12:09 ` Vinayak Menon
2018-01-24 12:21 ` Michal Hocko
2018-01-30 12:01 ` Vinayak Menon
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=20180123160509.GT1526@dhcp22.suse.cz \
--to=mhocko@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=jack@suse.cz \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=minchan@kernel.org \
--cc=riel@redhat.com \
--cc=torvalds@linux-foundation.org \
--cc=vinmenon@codeaurora.org \
--cc=will.deacon@arm.com \
--cc=ying.huang@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox