Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1319381imm; Mon, 9 Jul 2018 23:01:06 -0700 (PDT) X-Google-Smtp-Source: AAOMgpfuOsUBiJA3SiAvOOE7MFLDHI9x/fqZcJ/gxJeK0DjWpWUuwMxgNo4JFU70DwyAD4i+rDtc X-Received: by 2002:a62:968f:: with SMTP id s15-v6mr24193775pfk.191.1531202466776; Mon, 09 Jul 2018 23:01:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531202466; cv=none; d=google.com; s=arc-20160816; b=SjE1GfNuxaRc6o0gyjUBbtf0d//aXua4RH9qBBCKprrTL40g3yt/6F4cgUyNGiUn0R ICnN302JtV/Vjh31i7+jQ3Uh+CO+b/WH9t8Ou3aajRb4NpoygUToBbXHfVrBw/sEG0av ssG5dWkWqTbWU7GQfRnQr/1y/K4NcVTg2V+AqTPyI5UoczhXbT1WDMXs6QGzlTCzkLOE O6dJ65K1QFebcxkuF7BTbc8rQladwuR4+y2VKr7PVXjFTkG7tvYFrQV+fZxRRkftzwUJ Ke3kXB1g7s/wYQdbFZlVgCbYalVdcIHb+/Mk8y6tOg84yquGmwG6AMOrwond2WWvAeWo 8scQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=RUwxP9WRSHYbpbIsqOXkRfDHcGn0pCfNbYGARSG/nPk=; b=b3SGYeCK7wVCFq1hRhlTRrp4Xp2PTUU+VB6y1cUKfcOYIplaoBO3WRjnXX7hShfT5x wGYUyVW8NseSQpvvf2uFf/b+fgbydbXdqq83Y5T/cXM7mWbW7VlunZN2DnEwildh3teT QOc6+7qXQEkZedGrnKhYP8Bd/ItKzMT1TIxfq9L8GZGyZc6iNlWN3bVFgC1X+Kwmk9V7 XaExlDDuPT0/O031Nm0wSKoBp9Js//N0ax2JYhJqC1F4DT6rV+bHGsV1kLZ+h0ZemljP QC81vJMB8gZrrzJBKlXRYVGQ8reyaWRUlaGeiZzPwEeDOv5rTYYjy5+H34DjvrVJiPv4 gKoA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t89-v6si17270741pfe.59.2018.07.09.23.00.51; Mon, 09 Jul 2018 23:01:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751515AbeGJGAC (ORCPT + 99 others); Tue, 10 Jul 2018 02:00:02 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:43840 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750934AbeGJGAA (ORCPT ); Tue, 10 Jul 2018 02:00:00 -0400 Received: by mail-wr1-f67.google.com with SMTP id b15-v6so13203538wrv.10 for ; Mon, 09 Jul 2018 23:00:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=RUwxP9WRSHYbpbIsqOXkRfDHcGn0pCfNbYGARSG/nPk=; b=XW95cmj4MywdEjZ4I9XYeMsKTMlbT7JeQv0yDE0tCOIL61QYu47WMrGYjgOZ/qebNU lw+2SJEpAFVBS2LSfa04qB7PtROrDM1DFTvQOlzMB9cOMc70Ja06WQcqtWZRzP+2TtWk fAIbXu3C+jq2yHGyFw/KL+ZI9hFYu0PHThvJxdOoriovgcwaZNnctDJQtGUG6Bs2yE9J JeJtoNLs0Xy+zt8wF/CBk8/l7t9TejxfDE5d2L5Dad3JXi6SscOMs4Bfs7/qn5+1vuPL E4ANcmh47rimSZxtnWTLqy1FGfevokKf1GZWTKfN8VKUfIDJWzOM7Uy65EUoWQ0VGiZE LuxQ== X-Gm-Message-State: AOUpUlHsNx7Q4WOWsxyEaB8k4c+NWrrwhpSD37N7oX2u0JMFNFamOhYe sF4amgenSK3mGqjIlOTUs9O0Pdel X-Received: by 2002:adf:8919:: with SMTP id s25-v6mr5600377wrs.89.1531202399709; Mon, 09 Jul 2018 22:59:59 -0700 (PDT) Received: from techadventures.net (techadventures.net. [62.201.165.239]) by smtp.gmail.com with ESMTPSA id m136-v6sm11980291wma.32.2018.07.09.22.59.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 09 Jul 2018 22:59:58 -0700 (PDT) Received: by techadventures.net (Postfix, from userid 1000) id E3F85123D0F; Tue, 10 Jul 2018 07:59:57 +0200 (CEST) Date: Tue, 10 Jul 2018 07:59:57 +0200 From: Oscar Salvador To: Andrew Morton Cc: Pavel Tatashin , steven.sistare@oracle.com, daniel.m.jordan@oracle.com, linux-kernel@vger.kernel.org, kirill.shutemov@linux.intel.com, mhocko@suse.com, linux-mm@kvack.org, dan.j.williams@intel.com, jack@suse.cz, jglisse@redhat.com, jrdr.linux@gmail.com, bhe@redhat.com, gregkh@linuxfoundation.org, vbabka@suse.cz, richard.weiyang@gmail.com, dave.hansen@intel.com, rientjes@google.com, mingo@kernel.org Subject: Re: [PATCH v4 0/3] sparse_init rewrite Message-ID: <20180710055957.GA7380@techadventures.net> References: <20180709175312.11155-1-pasha.tatashin@oracle.com> <20180709142928.c8af4a1ddf80c407fe66b224@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180709142928.c8af4a1ddf80c407fe66b224@linux-foundation.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jul 09, 2018 at 02:29:28PM -0700, Andrew Morton wrote: > On Mon, 9 Jul 2018 13:53:09 -0400 Pavel Tatashin wrote: > > > In sparse_init() we allocate two large buffers to temporary hold usemap and > > memmap for the whole machine. However, we can avoid doing that if we > > changed sparse_init() to operated on per-node bases instead of doing it on > > the whole machine beforehand. > > > > As shown by Baoquan > > http://lkml.kernel.org/r/20180628062857.29658-1-bhe@redhat.com > > > > The buffers are large enough to cause machine stop to boot on small memory > > systems. > > > > These patches should be applied on top of Baoquan's work, as > > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER is removed in that work. > > > > For the ease of review, I split this work so the first patch only adds new > > interfaces, the second patch enables them, and removes the old ones. > > This clashes pretty significantly with patches from Baoquan and Oscar: > > mm-sparse-make-sparse_init_one_section-void-and-remove-check.patch > mm-sparse-make-sparse_init_one_section-void-and-remove-check-fix.patch > mm-sparse-make-sparse_init_one_section-void-and-remove-check-fix-2.patch Does this patchset still clash with those patches? If so, since those patches are already in the -mm tree, would it be better to re-base the patchset on top of that? Thanks -- Oscar Salvador SUSE L3