From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752487AbdHNNms (ORCPT ); Mon, 14 Aug 2017 09:42:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:40807 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751365AbdHNNmq (ORCPT ); Mon, 14 Aug 2017 09:42:46 -0400 Date: Mon, 14 Aug 2017 15:42:43 +0200 From: Michal Hocko To: Pasha Tatashin Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, davem@davemloft.net, willy@infradead.org, ard.biesheuvel@linaro.org, will.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org, Mel Gorman Subject: Re: [v6 04/15] mm: discard memblock data later Message-ID: <20170814134243.GM19063@dhcp22.suse.cz> References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com> <20170811093249.GE30811@dhcp22.suse.cz> <42a04441-47ad-2fa0-ca3c-784c717213f7@oracle.com> <20170814113445.GE19063@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon 14-08-17 09:39:17, Pasha Tatashin wrote: > >>#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in > >>nobootmem headfile. > > > >This is the standard way to do this. And it is usually preferred to > >proliferate ifdefs in the code. > > Hi Michal, > > As you suggested, I sent-out this patch separately. If you feel strongly, > that this should be updated to have stubs for platforms that do not > implement memblock, please send a reply to that e-mail, so those who do not > follow this tread will see it. Otherwise, I can leave it as is, page_alloc > file already has a number memblock related ifdefs all of which can be > cleaned out once every platform implements it (is it even achievable?) I do not think this needs a repost just for this. This was merely a JFYI, in case you would need to repost for other reasons then just update that as well. But nothing really earth shattering. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Date: Mon, 14 Aug 2017 13:42:43 +0000 Subject: Re: [v6 04/15] mm: discard memblock data later Message-Id: <20170814134243.GM19063@dhcp22.suse.cz> List-Id: References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com> <20170811093249.GE30811@dhcp22.suse.cz> <42a04441-47ad-2fa0-ca3c-784c717213f7@oracle.com> <20170814113445.GE19063@dhcp22.suse.cz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On Mon 14-08-17 09:39:17, Pasha Tatashin wrote: > >>#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in > >>nobootmem headfile. > > > >This is the standard way to do this. And it is usually preferred to > >proliferate ifdefs in the code. > > Hi Michal, > > As you suggested, I sent-out this patch separately. If you feel strongly, > that this should be updated to have stubs for platforms that do not > implement memblock, please send a reply to that e-mail, so those who do not > follow this tread will see it. Otherwise, I can leave it as is, page_alloc > file already has a number memblock related ifdefs all of which can be > cleaned out once every platform implements it (is it even achievable?) I do not think this needs a repost just for this. This was merely a JFYI, in case you would need to repost for other reasons then just update that as well. But nothing really earth shattering. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f72.google.com (mail-wm0-f72.google.com [74.125.82.72]) by kanga.kvack.org (Postfix) with ESMTP id 20A916B025F for ; Mon, 14 Aug 2017 09:42:47 -0400 (EDT) Received: by mail-wm0-f72.google.com with SMTP id a186so14018940wmh.9 for ; Mon, 14 Aug 2017 06:42:47 -0700 (PDT) Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id t9si5571099wrb.3.2017.08.14.06.42.45 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 14 Aug 2017 06:42:46 -0700 (PDT) Date: Mon, 14 Aug 2017 15:42:43 +0200 From: Michal Hocko Subject: Re: [v6 04/15] mm: discard memblock data later Message-ID: <20170814134243.GM19063@dhcp22.suse.cz> References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com> <20170811093249.GE30811@dhcp22.suse.cz> <42a04441-47ad-2fa0-ca3c-784c717213f7@oracle.com> <20170814113445.GE19063@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Pasha Tatashin Cc: linux-kernel@vger.kernel.org, sparclinux@vger.kernel.org, linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org, linux-arm-kernel@lists.infradead.org, x86@kernel.org, kasan-dev@googlegroups.com, borntraeger@de.ibm.com, heiko.carstens@de.ibm.com, davem@davemloft.net, willy@infradead.org, ard.biesheuvel@linaro.org, will.deacon@arm.com, catalin.marinas@arm.com, sam@ravnborg.org, Mel Gorman On Mon 14-08-17 09:39:17, Pasha Tatashin wrote: > >>#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in > >>nobootmem headfile. > > > >This is the standard way to do this. And it is usually preferred to > >proliferate ifdefs in the code. > > Hi Michal, > > As you suggested, I sent-out this patch separately. If you feel strongly, > that this should be updated to have stubs for platforms that do not > implement memblock, please send a reply to that e-mail, so those who do not > follow this tread will see it. Otherwise, I can leave it as is, page_alloc > file already has a number memblock related ifdefs all of which can be > cleaned out once every platform implements it (is it even achievable?) I do not think this needs a repost just for this. This was merely a JFYI, in case you would need to repost for other reasons then just update that as well. But nothing really earth shattering. -- Michal Hocko SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 From: mhocko@kernel.org (Michal Hocko) Date: Mon, 14 Aug 2017 15:42:43 +0200 Subject: [v6 04/15] mm: discard memblock data later In-Reply-To: References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-5-git-send-email-pasha.tatashin@oracle.com> <20170811093249.GE30811@dhcp22.suse.cz> <42a04441-47ad-2fa0-ca3c-784c717213f7@oracle.com> <20170814113445.GE19063@dhcp22.suse.cz> Message-ID: <20170814134243.GM19063@dhcp22.suse.cz> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Mon 14-08-17 09:39:17, Pasha Tatashin wrote: > >>#ifdef CONFIG_MEMBLOCK in page_alloc, or define memblock_discard() stubs in > >>nobootmem headfile. > > > >This is the standard way to do this. And it is usually preferred to > >proliferate ifdefs in the code. > > Hi Michal, > > As you suggested, I sent-out this patch separately. If you feel strongly, > that this should be updated to have stubs for platforms that do not > implement memblock, please send a reply to that e-mail, so those who do not > follow this tread will see it. Otherwise, I can leave it as is, page_alloc > file already has a number memblock related ifdefs all of which can be > cleaned out once every platform implements it (is it even achievable?) I do not think this needs a repost just for this. This was merely a JFYI, in case you would need to repost for other reasons then just update that as well. But nothing really earth shattering. -- Michal Hocko SUSE Labs