linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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: Mon, 18 Apr 2016 14:38:13 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1604181437220.10562@chino.kir.corp.google.com> (raw)
In-Reply-To: <87y48phkk2.fsf@vitty.brq.redhat.com>

On Thu, 7 Apr 2016, Vitaly Kuznetsov wrote:

> >> > This patchset continues the work I started with:
> >> > 
> >> > commit 31bc3858ea3ebcc3157b3f5f0e624c5962f5a7a6
> >> > Author: Vitaly Kuznetsov <vkuznets@redhat.com>
> >> > Date:   Tue Mar 15 14:56:48 2016 -0700
> >> > 
> >> >     memory-hotplug: add automatic onlining policy for the newly added memory
> >> > 
> >> > Initially I was going to stop there and bring the policy setting logic to
> >> > userspace. I met two issues on this way:
> >> > 
> >> > 1) It is possible to have memory hotplugged at boot (e.g. with QEMU). These
> >> >    blocks stay offlined if we turn the onlining policy on by userspace.
> >> > 
> >> > 2) My attempt to bring this policy setting to systemd failed, systemd
> >> >    maintainers suggest to change the default in kernel or ... to use tmpfiles.d
> >> >    to alter the policy (which looks like a hack to me): 
> >> >    https://github.com/systemd/systemd/pull/2938
> >> 
> >> That discussion really didn't come to a conclusion and I don't
> >> understand why you consider Lennert's "recommended way" to be a hack?
> >> 
> >> > Here I suggest to add a config option to set the default value for the policy
> >> > and a kernel command line parameter to make the override.
> >> 
> >> But the patchset looks pretty reasonable regardless of the above.
> >> 
> >
> > I don't understand why initscripts simply cannot crawl sysfs memory blocks 
> > and online them for the same behavior.
> 
> Yes, they can. With this patchset I don't bring any new features, it's
> rather a convenience so linux distros can make memory hotplug work
> 'out of the box' without such distro-specific initscripts. Memory
> hotplug is a standard feature of all major virt technologies so I think
> it's pretty reasonable to have an option to make it work 'by default'
> available.
> 

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.

  reply	other threads:[~2016-04-18 21:38 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-06 13:45 [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy 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 [this message]
2016-04-19  7:29         ` Vitaly Kuznetsov
2016-04-20 21:35           ` David Rientjes
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.1604181437220.10562@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;
as well as URLs for NNTP newsgroup(s).