linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Vinayak Menon <vinmenon@codeaurora.org>
To: Michal Hocko <mhocko@kernel.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: Wed, 24 Jan 2018 17:39:44 +0530	[thread overview]
Message-ID: <7e50564b-960d-5a07-47ec-6b1d86a3c32d@codeaurora.org> (raw)
In-Reply-To: <20180124111130.GB28465@dhcp22.suse.cz>

On 1/24/2018 4:41 PM, Michal Hocko wrote:
> On Wed 24-01-18 16:13:06, Vinayak Menon wrote:
>> On 1/24/2018 3:08 PM, Michal Hocko wrote:
> [...]
>>> Try to be more realistic. We have way too many sysctls. Some of them are
>>> really implementation specific and then it is not really trivial to get
>>> rid of them because people tend to (think they) depend on them. This is
>>> a user interface like any others and we do not add them without a due
>>> scrutiny. Moreover we do have an interface to suppress the effect of the
>>> faultaround. Instead you are trying to add another tunable for something
>>> that we can live without altogether. See my point?
>> I agree on the sysctl part. But why should we disable faultaround and
>> not find a way to make it useful ?
> I didn't say that. Please read what I've written. I really hate your new
> sysctl, because that is not a solution. If you can find a different one
> than disabling it then go ahead. But do not try to put burden to users
> because they know what to set. Because they won't.

What about an expert level config option which is by default disabled ?
Whether to consider faultaround ptes as old or young is dependent on architectural details that can't be
gathered at runtime by reading some system registers. This needs to be figured out by experiments, just like
how a value for watermark_scale_factor is arrived at. So the user, in this case an engineer expert in this area
decides whether the option can be enabled or not in the build.
I agree that it need not be a sysctl, but what is the problem that you see in making it a expert level config ?
How is it a burden to a non-expert user ?

Thanks,
Vinayak

--
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>

  reply	other threads:[~2018-01-24 12:09 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
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 [this message]
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=7e50564b-960d-5a07-47ec-6b1d86a3c32d@codeaurora.org \
    --to=vinmenon@codeaurora.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=mhocko@kernel.org \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=torvalds@linux-foundation.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