Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1372540 > unrolled thread

[PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

Back to article view | Back to linux.kernel

Contents

  [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-04-06 15:50 +0200
    Re: [PATCH 0/2] memory_hotplug: introduce config and command line  options to set the default onlining policy Andrew Morton <akpm@linux-foundation.org> - 2016-04-06 21:00 +0200
      Re: [PATCH 0/2] memory_hotplug: introduce config and command line  options to set the default onlining policy David Rientjes <rientjes@google.com> - 2016-04-07 00:20 +0200
        Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-04-07 10:50 +0200
      Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy Vitaly Kuznetsov <vkuznets@redhat.com> - 2016-04-07 10:50 +0200

#1372540 — [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

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

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.

Vitaly Kuznetsov (2):
  memory_hotplug: introduce CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE
  memory_hotplug: introduce memhp_default_state= command line parameter

 Documentation/kernel-parameters.txt |  8 ++++++++
 Documentation/memory-hotplug.txt    |  9 +++++----
 mm/Kconfig                          | 16 ++++++++++++++++
 mm/memory_hotplug.c                 | 15 +++++++++++++++
 4 files changed, 44 insertions(+), 4 deletions(-)

-- 
2.5.5

[toc] | [next] | [standalone]

#1372737 — Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Wed,  6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov <vkuznets@redhat.com> 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.

[toc] | [prev] | [next] | [standalone]

#1372894 — Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

On Wed, 6 Apr 2016, Andrew Morton 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.

[toc] | [prev] | [next] | [standalone]

#1373163

David Rientjes <rientjes@google.com> writes:

> On Wed, 6 Apr 2016, Andrew Morton 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.

-- 
  Vitaly

[toc] | [prev] | [next] | [standalone]

#1373165

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed,  6 Apr 2016 15:45:10 +0200 Vitaly Kuznetsov <vkuznets@redhat.com> 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?

Just the name. To me 'tmpfiles.d' doesn't sound like an appropriate
place to search for kernel tunables settings. It would be much better in
case we had something like 'tunables.d' for that.

-- 
  Vitaly

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web