From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.5 required=3.0 tests=MAILING_LIST_MULTI,SPF_PASS, USER_AGENT_MUTT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 654CEC43382 for ; Wed, 26 Sep 2018 14:23:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 27CBD20676 for ; Wed, 26 Sep 2018 14:23:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 27CBD20676 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728253AbeIZUgm (ORCPT ); Wed, 26 Sep 2018 16:36:42 -0400 Received: from mx2.suse.de ([195.135.220.15]:52898 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727504AbeIZUgm (ORCPT ); Wed, 26 Sep 2018 16:36:42 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 3B687AC38; Wed, 26 Sep 2018 14:23:26 +0000 (UTC) Date: Wed, 26 Sep 2018 16:23:19 +0200 From: Michal Hocko To: Mike Rapoport Cc: linux-mm@kvack.org, Andrew Morton , Catalin Marinas , Chris Zankel , "David S. Miller" , Geert Uytterhoeven , Greentime Hu , Greg Kroah-Hartman , Guan Xuetao , Ingo Molnar , "James E.J. Bottomley" , Jonas Bonn , Jonathan Corbet , Ley Foon Tan , Mark Salter , Martin Schwidefsky , Matt Turner , Michael Ellerman , Michal Simek , Palmer Dabbelt , Paul Burton , Richard Kuo , Richard Weinberger , Rich Felker , Russell King , Serge Semin , Thomas Gleixner , Tony Luck , Vineet Gupta , Yoshinori Sato , linux-alpha@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-c6x-dev@linux-c6x.org, linux-hexagon@vger.kernel.org, linux-ia64@vger.kernel.org, linux-kernel@vger.kernel.org, linux-m68k@lists.linux-m68k.org, linux-mips@linux-mips.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-um@lists.infradead.org, nios2-dev@lists.rocketboards.org, openrisc@lists.librecores.org, sparclinux@vger.kernel.org, uclinux-h8-devel@lists.sourceforge.jp Subject: Re: [PATCH 14/30] memblock: add align parameter to memblock_alloc_node() Message-ID: <20180926142319.GA6278@dhcp22.suse.cz> References: <1536927045-23536-1-git-send-email-rppt@linux.vnet.ibm.com> <1536927045-23536-15-git-send-email-rppt@linux.vnet.ibm.com> <20180926093127.GO6278@dhcp22.suse.cz> <20180926093648.GP6278@dhcp22.suse.cz> <20180926134335.GF4628@rapoport-lnx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180926134335.GF4628@rapoport-lnx> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed 26-09-18 16:43:35, Mike Rapoport wrote: > On Wed, Sep 26, 2018 at 11:36:48AM +0200, Michal Hocko wrote: > > On Wed 26-09-18 11:31:27, Michal Hocko wrote: > > > On Fri 14-09-18 15:10:29, Mike Rapoport wrote: > > > > With the align parameter memblock_alloc_node() can be used as drop in > > > > replacement for alloc_bootmem_pages_node() and __alloc_bootmem_node(), > > > > which is done in the following patches. > > > > > > /me confused. Why do we need this patch at all? Maybe it should be > > > folded into the later patch you are refereing here? > > > > OK, I can see 1536927045-23536-17-git-send-email-rppt@linux.vnet.ibm.com > > now. If you are going to repost for whatever reason please merge those > > two. Also I would get rid of the implicit "0 implies SMP_CACHE_BYTES" > > behavior. It is subtle and you have to dig deep to find that out. Why > > not make it explicit? > > Agree. I'd just prefer to make it a separate patch rather then resend the > whole series. Sure, no objection from me. -- Michal Hocko SUSE Labs