From: David Rientjes <rientjes@google.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, Jonathan Corbet <corbet@lwn.net>,
Dan Williams <dan.j.williams@intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
Mel Gorman <mgorman@suse.de>,
David Vrabel <david.vrabel@citrix.com>,
Igor Mammedov <imammedo@redhat.com>,
Lennart Poettering <lennart@poettering.net>
Subject: Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy
Date: Wed, 20 Apr 2016 14:35:52 -0700 (PDT) [thread overview]
Message-ID: <alpine.DEB.2.10.1604201430280.4829@chino.kir.corp.google.com> (raw)
In-Reply-To: <87zisq2h0o.fsf@vitty.brq.redhat.com>
On Tue, 19 Apr 2016, Vitaly Kuznetsov wrote:
> > I'd personally disagree that we need more and more config options to take
> > care of something that an initscript can easily do and most distros
> > already have their own initscripts that this can be added to. I don't see
> > anything that the config option adds.
>
> Yes, but why does every distro need to solve the exact same issue by
> a distro-specific init script when we can allow setting reasonable
> default in kernel?
>
No, only distros that want to change the long-standing default which is
"offline" since they apparently aren't worried about breaking existing
userspace.
Changing defaults is always risky business in the kernel, especially when
it's long standing. If the default behavior is changeable, userspace
needs to start testing for that and acting accordingly if it actually
wants to default to offline (and there are existing tools that suppose the
long-standing default). The end result is that the kernel default doesn't
matter anymore, we've just pushed it to userspace to either online or
offline at the time of hotplug.
> If the config option itself is a problem (though I don't understand why)
> we can get rid of it making the default 'online' and keeping the command
> line parameter to disable it for cases when something goes wrong but why
> not leave an option for those who want it the other way around?
>
That could break existing userspace that assumes the default is offline;
if users are currently hotadding memory and then onlining it when needed
rather than immediately, they break. So that's not a possibility.
> Other than the above, let's imagine a 'unikernel' scenario when there
> are no initscripts and we're in a virtualized environment. We may want to
> have memory hotplug there too, but where would we put the 'onlining'
> logic? In every userspace we want to run? This doesn't sound right.
>
Nobody is resisting hotplug notifiers.
--
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:[~2016-04-20 21:35 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-06 13:45 Vitaly Kuznetsov
2016-04-06 13:45 ` [PATCH 1/2] memory_hotplug: introduce CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE Vitaly Kuznetsov
2016-04-06 13:45 ` [PATCH 2/2] memory_hotplug: introduce memhp_default_state= command line parameter Vitaly Kuznetsov
2016-04-06 18:53 ` [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy Andrew Morton
2016-04-06 22:13 ` David Rientjes
2016-04-07 8:47 ` Vitaly Kuznetsov
2016-04-18 21:38 ` David Rientjes
2016-04-19 7:29 ` Vitaly Kuznetsov
2016-04-20 21:35 ` David Rientjes [this message]
2016-04-21 7:25 ` Vitaly Kuznetsov
2016-04-07 8:42 ` Vitaly Kuznetsov
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=alpine.DEB.2.10.1604201430280.4829@chino.kir.corp.google.com \
--to=rientjes@google.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=david.vrabel@citrix.com \
--cc=imammedo@redhat.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=lennart@poettering.net \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=vkuznets@redhat.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