Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757900Ab3GWOyg (ORCPT ); Tue, 23 Jul 2013 10:54:36 -0400 Received: from co1ehsobe001.messaging.microsoft.com ([216.32.180.184]:27904 "EHLO co1outboundpool.messaging.microsoft.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757874Ab3GWOye convert rfc822-to-8bit (ORCPT ); Tue, 23 Jul 2013 10:54:34 -0400 X-Forefront-Antispam-Report: CIP:131.107.125.8;KIP:(null);UIP:(null);IPV:NLI;H:TK5EX14HUBC105.redmond.corp.microsoft.com;RD:autodiscover.service.exchange.microsoft.com;EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(zz98dI9371I936eI542I1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1de097h8275dhz2fh2a8h683h839h944hd24hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1b0ah1d07h1d0ch1d2eh1d3fh1de9h1dfeh1dffh1e1dh9a9j1155h) X-Forefront-Antispam-Report-Untrusted: CIP:157.56.240.21;KIP:(null);UIP:(null);(null);H:BL2PRD0310HT002.namprd03.prod.outlook.com;R:internal;EFV:INT X-Forefront-Antispam-Report-Untrusted: SFV:NSPM;SFS:(377454003)(51704005)(189002)(199002)(24454002)(377424004)(13464003)(69226001)(76786001)(16406001)(51856001)(74662001)(47446002)(74706001)(74502001)(77096001)(47976001)(56776001)(50986001)(56816003)(76796001)(74876001)(66066001)(47736001)(49866001)(65816001)(53806001)(83072001)(54356001)(74316001)(80022001)(4396001)(76482001)(46102001)(79102001)(63696002)(33646001)(19580395003)(54316002)(83322001)(81342001)(19580405001)(59766001)(81542001)(77982001)(74366001)(31966008)(76576001)(24736002);DIR:OUT;SFP:;SCL:1;SRVR:SN2PR03MB062;H:SN2PR03MB061.namprd03.prod.outlook.com;CLIP:173.61.119.57;RD:InfoNoRecords;MX:1;A:1;LANG:en; From: KY Srinivasan To: Michal Hocko CC: "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 Thread-Topic: [PATCH 1/1] Drivers: base: memory: Export symbols for onlining memory blocks Thread-Index: AQHOhLBUexA6H+ozR02R0nup8ZuRHJlwpwQAgAGspIA= Date: Tue, 23 Jul 2013 14:52:36 +0000 Message-ID: References: <1374261785-1615-1-git-send-email-kys@microsoft.com> <20130722123716.GB24400@dhcp22.suse.cz> In-Reply-To: <20130722123716.GB24400@dhcp22.suse.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.61.119.57] x-forefront-prvs: 0916FC3A18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-OrganizationHeadersPreserved: SN2PR03MB062.namprd03.prod.outlook.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GMAIL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%KVACK.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LINUX-FOUNDATION.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CMPXCHG.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VRFY.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%REDHAT.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%GOOGLE.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%VGER.KERNEL.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LINUXFOUNDATION.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%SUSE.CZ$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%LINUXDRIVERPROJECT.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%FIRSTFLOOR.ORG$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%CANONICAL.COM$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-FOPE-CONNECTOR: Id%59$Dn%AEPFLE.DE$RO%2$TLS%6$FQDN%corpf5vips-237160.customer.frontbridge.com$TlsDn% X-CrossPremisesHeadersPromoted: TK5EX14HUBC105.redmond.corp.microsoft.com X-CrossPremisesHeadersFiltered: TK5EX14HUBC105.redmond.corp.microsoft.com X-OriginatorOrg: microsoft.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2234 Lines: 53 > -----Original Message----- > From: Michal Hocko [mailto:mhocko@suse.cz] > Sent: Monday, July 22, 2013 8:37 AM > To: KY Srinivasan > Cc: 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 > > On Fri 19-07-13 12:23:05, K. Y. Srinivasan wrote: > > The current machinery for hot-adding memory requires having udev > > rules to bring the memory segments online. Export the necessary functionality > > to to bring the memory segment online without involving user space code. > > Why? Who is going to use it and for what purpose? > If you need to do it from the kernel cannot you use usermod helper > thread? > > Besides that this is far from being complete. memory_block_change_state > seems to depend on device_hotplug_lock and find_memory_block is > currently called with mem_sysfs_mutex held. None of them is exported > AFAICS. You are right; not all of the required symbols are exported (yet). Let me answer your other questions first: The Hyper-V balloon driver can use this functionality. I have prototyped the in-kernel "onlining" of hot added memory without requiring any help from user level code that performs significantly better than having user level code involved in the hot add process. With this change, I am able to successfully hot-add and online the hot-added memory even under extreme memory pressure which is what you would want given that we are hot-adding memory to alleviate memory pressure. The current scheme of involving user level code to close this loop obviously does not perform well under high memory pressure. I can, if you prefer export all of the necessary functionality in one patch. Regards, K. Y -- 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/