Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756345Ab3GYPD6 (ORCPT ); Thu, 25 Jul 2013 11:03:58 -0400 Received: from www.sr71.net ([198.145.64.142]:34527 "EHLO blackbird.sr71.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755609Ab3GYPD5 (ORCPT ); Thu, 25 Jul 2013 11:03:57 -0400 Message-ID: <51F13E51.7040808@sr71.net> Date: Thu, 25 Jul 2013 08:03:45 -0700 From: Dave Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: KY Srinivasan CC: Michal Hocko , "gregkh@linuxfoundation.org" , "linux-kernel@vger.kernel.org" , "devel@linuxdriverproject.org" , "olaf@aepfle.de" , "apw@canonical.com" , "andi@firstfloor.org" , "akpm@linux-foundation.org" , "linux-mm@kvack.org" , "kamezawa.hiroyuki@gmail.com" , "hannes@cmpxchg.org" , "yinghan@google.com" , "jasowang@redhat.com" , "kay@vrfy.org" Subject: Re: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining memory blocks References: <1374261785-1615-1-git-send-email-kys@microsoft.com> <20130722123716.GB24400@dhcp22.suse.cz> <51EEA11D.4030007@intel.com> <3318be0a96cb4d05838d76dc9d088cc0@SN2PR03MB061.namprd03.prod.outlook.com> <51EEA89F.9070309@intel.com> <9f351a549e76483d9148f87535567ea0@SN2PR03MB061.namprd03.prod.outlook.com> <51F00415.8070104@sr71.net> <51F040E8.1030507@intel.com> <20130725075705.GD12818@dhcp22.suse.cz> <4f440c8d96f34711a3f06fb18702a297@SN2PR03MB061.namprd03.prod.outlook.com> In-Reply-To: <4f440c8d96f34711a3f06fb18702a297@SN2PR03MB061.namprd03.prod.outlook.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1232 Lines: 23 On 07/25/2013 04:14 AM, KY Srinivasan wrote: > As promised, I have sent out the patches for (a) an implementation of an in-kernel API > for onlining and a consumer for this API. While I don't know the exact reason why the > user mode code is delayed (under some low memory conditions), what is the harm in having > a mechanism to online memory that has been hot added without involving user space code. KY, your potential problem, not being able to online more memory because of a shortage of memory, is a serious one. However, this potential issue exists in long-standing code, and potentially affects all users of memory hotplug. The problem has not been described in sufficient detail for the rest of the developers to tell if you are facing a new problem, or whether *any* proposed solution will help the problem you face. Your propsed solution changes the semantics of existing user/kernel interfaces, duplicates existing functionality, and adds code complexity to the kernel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/