From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753394AbdHKQAF (ORCPT ); Fri, 11 Aug 2017 12:00:05 -0400 Received: from userp1040.oracle.com ([156.151.31.81]:37967 "EHLO userp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752989AbdHKQAD (ORCPT ); Fri, 11 Aug 2017 12:00:03 -0400 Subject: Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw To: Michal Hocko 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 References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-8-git-send-email-pasha.tatashin@oracle.com> <20170811123953.GI30811@dhcp22.suse.cz> From: Pasha Tatashin Message-ID: <545b7230-2c09-d2f9-f26a-05ef395c36d4@oracle.com> Date: Fri, 11 Aug 2017 11:58:46 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170811123953.GI30811@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/11/2017 08:39 AM, Michal Hocko wrote: > On Mon 07-08-17 16:38:41, Pavel Tatashin wrote: >> A new variant of memblock_virt_alloc_* allocations: >> memblock_virt_alloc_try_nid_raw() >> - Does not zero the allocated memory >> - Does not panic if request cannot be satisfied > > OK, this looks good but I would not introduce memblock_virt_alloc_raw > here because we do not have any users. Please move that to "mm: optimize > early system hash allocations" which actually uses the API. It would be > easier to review it that way. > >> Signed-off-by: Pavel Tatashin >> Reviewed-by: Steven Sistare >> Reviewed-by: Daniel Jordan >> Reviewed-by: Bob Picco > > other than that > Acked-by: Michal Hocko Sure, I could do this, but as I understood from earlier Dave Miller's comments, we should do one logical change at a time. Hence, introduce API in one patch use it in another. So, this is how I tried to organize this patch set. Is this assumption incorrect? From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pasha Tatashin Date: Fri, 11 Aug 2017 15:58:46 +0000 Subject: Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw Message-Id: <545b7230-2c09-d2f9-f26a-05ef395c36d4@oracle.com> List-Id: References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-8-git-send-email-pasha.tatashin@oracle.com> <20170811123953.GI30811@dhcp22.suse.cz> In-Reply-To: <20170811123953.GI30811@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-arm-kernel@lists.infradead.org On 08/11/2017 08:39 AM, Michal Hocko wrote: > On Mon 07-08-17 16:38:41, Pavel Tatashin wrote: >> A new variant of memblock_virt_alloc_* allocations: >> memblock_virt_alloc_try_nid_raw() >> - Does not zero the allocated memory >> - Does not panic if request cannot be satisfied > > OK, this looks good but I would not introduce memblock_virt_alloc_raw > here because we do not have any users. Please move that to "mm: optimize > early system hash allocations" which actually uses the API. It would be > easier to review it that way. > >> Signed-off-by: Pavel Tatashin >> Reviewed-by: Steven Sistare >> Reviewed-by: Daniel Jordan >> Reviewed-by: Bob Picco > > other than that > Acked-by: Michal Hocko Sure, I could do this, but as I understood from earlier Dave Miller's comments, we should do one logical change at a time. Hence, introduce API in one patch use it in another. So, this is how I tried to organize this patch set. Is this assumption incorrect? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yw0-f198.google.com (mail-yw0-f198.google.com [209.85.161.198]) by kanga.kvack.org (Postfix) with ESMTP id B0E176B02B4 for ; Fri, 11 Aug 2017 11:59:28 -0400 (EDT) Received: by mail-yw0-f198.google.com with SMTP id g129so63637363ywh.11 for ; Fri, 11 Aug 2017 08:59:28 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com. [156.151.31.81]) by mx.google.com with ESMTPS id p204si330956ywc.445.2017.08.11.08.59.27 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 11 Aug 2017 08:59:27 -0700 (PDT) Subject: Re: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-8-git-send-email-pasha.tatashin@oracle.com> <20170811123953.GI30811@dhcp22.suse.cz> From: Pasha Tatashin Message-ID: <545b7230-2c09-d2f9-f26a-05ef395c36d4@oracle.com> Date: Fri, 11 Aug 2017 11:58:46 -0400 MIME-Version: 1.0 In-Reply-To: <20170811123953.GI30811@dhcp22.suse.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Michal Hocko 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 On 08/11/2017 08:39 AM, Michal Hocko wrote: > On Mon 07-08-17 16:38:41, Pavel Tatashin wrote: >> A new variant of memblock_virt_alloc_* allocations: >> memblock_virt_alloc_try_nid_raw() >> - Does not zero the allocated memory >> - Does not panic if request cannot be satisfied > > OK, this looks good but I would not introduce memblock_virt_alloc_raw > here because we do not have any users. Please move that to "mm: optimize > early system hash allocations" which actually uses the API. It would be > easier to review it that way. > >> Signed-off-by: Pavel Tatashin >> Reviewed-by: Steven Sistare >> Reviewed-by: Daniel Jordan >> Reviewed-by: Bob Picco > > other than that > Acked-by: Michal Hocko Sure, I could do this, but as I understood from earlier Dave Miller's comments, we should do one logical change at a time. Hence, introduce API in one patch use it in another. So, this is how I tried to organize this patch set. Is this assumption incorrect? -- 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: pasha.tatashin@oracle.com (Pasha Tatashin) Date: Fri, 11 Aug 2017 11:58:46 -0400 Subject: [v6 07/15] mm: defining memblock_virt_alloc_try_nid_raw In-Reply-To: <20170811123953.GI30811@dhcp22.suse.cz> References: <1502138329-123460-1-git-send-email-pasha.tatashin@oracle.com> <1502138329-123460-8-git-send-email-pasha.tatashin@oracle.com> <20170811123953.GI30811@dhcp22.suse.cz> Message-ID: <545b7230-2c09-d2f9-f26a-05ef395c36d4@oracle.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 08/11/2017 08:39 AM, Michal Hocko wrote: > On Mon 07-08-17 16:38:41, Pavel Tatashin wrote: >> A new variant of memblock_virt_alloc_* allocations: >> memblock_virt_alloc_try_nid_raw() >> - Does not zero the allocated memory >> - Does not panic if request cannot be satisfied > > OK, this looks good but I would not introduce memblock_virt_alloc_raw > here because we do not have any users. Please move that to "mm: optimize > early system hash allocations" which actually uses the API. It would be > easier to review it that way. > >> Signed-off-by: Pavel Tatashin >> Reviewed-by: Steven Sistare >> Reviewed-by: Daniel Jordan >> Reviewed-by: Bob Picco > > other than that > Acked-by: Michal Hocko Sure, I could do this, but as I understood from earlier Dave Miller's comments, we should do one logical change at a time. Hence, introduce API in one patch use it in another. So, this is how I tried to organize this patch set. Is this assumption incorrect?