Message-ID: <87oa931kzz.fsf@vitty.brq.redhat.com>
Date:	Thu, 21 Apr 2016 09:25:36 +0200
From:	Vitaly Kuznetsov <vkuznets@...hat.com>
To:	David Rientjes <rientjes@...gle.com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jonathan Corbet <corbet@....net>,
	Dan Williams <dan.j.williams@...el.com>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Mel Gorman <mgorman@...e.de>,
	David Vrabel <david.vrabel@...rix.com>,
	Igor Mammedov <imammedo@...hat.com>,
	Lennart Poettering <lennart@...ttering.net>
Subject: Re: [PATCH 0/2] memory_hotplug: introduce config and command line options to set the default onlining policy

David Rientjes <rientjes@...gle.com> writes:

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

"We don't break userspace". Yes, I know, but is there an example of such
userspace which is going to break?

E.g. RHEL7 ships the following udev rule by default:
# Memory hotadd request
SUBSYSTEM=="memory", ACTION=="add", ATTR{state}=="offline", ATTR{state}="online"

which is not very smart but it does the job (with issues I'm trying to
solve). I'm not aware of any breakages reported after it was introduced.

My understanding is that the legacy default 'offline' was introduced
before memory hotplug became a frequently used feature in virtual
machines. When you hotplug physical memory you go to your server room,
open your server, insert memory dimm, ... - in this scenario 'offline'
is a reasonable default. But in VMs mempory hotplug is usually an
automatic from host side -- we address high memory pressure/tenant
requests.

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

Yes, so I introduce a config option. Next thing we do we enable it in
'bleeding edge' distros, e.g. Fedora and see who complains. My guess is
that nobody is going to complain.

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

Yes, but we need to teach memory hotplug to every userspace instead.

-- 
  Vitaly

Powered by blists - more mailing lists