Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp6646744imm; Wed, 27 Jun 2018 10:50:45 -0700 (PDT) X-Google-Smtp-Source: AAOMgpegHF1toBlOgq9VYaHbi8DNnTx//2eo5i6bSdSa7fw3eQaQ6pJaY2+1Ghq8/2ZxaM/TmvgU X-Received: by 2002:a62:444c:: with SMTP id r73-v6mr6864251pfa.255.1530121845152; Wed, 27 Jun 2018 10:50:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1530121845; cv=none; d=google.com; s=arc-20160816; b=QJ0/5vH2Z8StyK6baGBhBeJCsaMwr3DDSo/DjxxQbZgAA9eMu8ScDcV95PPezgFt/l hB1IUKphih89OJaPwG5niEIWJ1oQdBjxN4ooXi5K9V/63Mkp+POI1+6jRl6JwX/kGkOW 7YItWja2JlEmcffFMKnm6fuyIRI8kxyLhrUvBYXOHd/IQdBe0yTIEcT1phJRxfOiB7Dk 0/HHIRAHdSz7l0uuKDNgW/RgIVP3u/EE6bD0JkcYnz+DgbjJVYqk6qLfiRdINn7f4WDa 3J1zlK9b/RPhBJmgPhWQeN7rtZ2xvXlXRjwxn7mHkxxIOIuNEtos66zn2SLmeJdYTWvH M9qQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature :arc-authentication-results; bh=WJ9yV/ShHcBKhdSFN0ip8XOS0BKKZdSKcIUg3X5aE0g=; b=pxqUu8E+nSqSaKX9wEkwoQu9/QLh0KZl3qRKkZB/7Mi1lB2ZSY3pAzPQvBiKnRZKiN jVk0H7uSTMLb5I4RdM13b8n7iI9460UXdmKxV6E8J2Vv6kox9Uz78kMpOMkhWIUiYcGP 068ceR4T3rTlqElTlQN/fAdh0UJQQzEd5IM84Lz9JYZwTZ0ni3K/1Sr6/zb8xsdclG6H eVnOhvFYrp1SKa79rHoXQv7Um6H4lATyu2nHwXeay01eKLb1XWutD+TD/2fn56lMaPXZ 4oRQBbvHeEtJiq6a6UsDPQOZc0eI+Rdm1yvcFv1ep30MHq2CqfWepUtEqZWnqHq2vLqM tTsw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=uljN4Brw; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o5-v6si3994122pgs.303.2018.06.27.10.50.31; Wed, 27 Jun 2018 10:50:45 -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; dkim=pass header.i=@oracle.com header.s=corp-2017-10-26 header.b=uljN4Brw; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=oracle.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935074AbeF0RsM (ORCPT + 99 others); Wed, 27 Jun 2018 13:48:12 -0400 Received: from aserp2120.oracle.com ([141.146.126.78]:38666 "EHLO aserp2120.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934627AbeF0RsJ (ORCPT ); Wed, 27 Jun 2018 13:48:09 -0400 Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w5RHdXOZ105372 for ; Wed, 27 Jun 2018 17:48:09 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : references : in-reply-to : from : date : message-id : subject : to : cc : content-type; s=corp-2017-10-26; bh=WJ9yV/ShHcBKhdSFN0ip8XOS0BKKZdSKcIUg3X5aE0g=; b=uljN4Brw/By/xwjwrVOVdSfDM/HXB31Z5FqPqc8yqeV0yMLrBfrBygKX0T7iQ7KFmzsK Ft1k2FruXjn3eNt7wotLD6/OcArIPlbDvD2RqQFDDEjDBGLdAGe0EUaOk77Lpe6cEcck 8aTFTUt4neJxot+12Tk9n03IZbQbX7wyIy1QjHqRjn6kOky4enkfLJA6vtVn7ytPPOrD 39JmNJpVVn4ipKbC9kVN4ZsoRXhA1DGRLkr/dSKsycxUUYFxF6qMdYLTjlMOKvGPVHJt LhCYgiMlEecduGvRLb3aL96gXbi8HLq4lh3Umxj6J/BpExI75AmkttY/6skzT9H+FxkU 0g== Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by aserp2120.oracle.com with ESMTP id 2jukhsdyng-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 27 Jun 2018 17:48:08 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w5RHm8vQ030368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Wed, 27 Jun 2018 17:48:08 GMT Received: from abhmp0001.oracle.com (abhmp0001.oracle.com [141.146.116.7]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w5RHm8sm018004 for ; Wed, 27 Jun 2018 17:48:08 GMT Received: from mail-ot0-f179.google.com (/74.125.82.179) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 27 Jun 2018 10:48:08 -0700 Received: by mail-ot0-f179.google.com with SMTP id w22-v6so3135155otk.5 for ; Wed, 27 Jun 2018 10:48:08 -0700 (PDT) X-Gm-Message-State: APt69E3exzsM8ggnvsiMudytCHbAeehl5fhTUngU046RYvCSa+Ksnq2a Jt5631VltoG+X8dQ7JxIjksLBlm93MU2j2j/TQs= X-Received: by 2002:a9d:20c5:: with SMTP id x63-v6mr781927ota.11.1530121684537; Wed, 27 Jun 2018 10:48:04 -0700 (PDT) MIME-Version: 1.0 References: <20180627013116.12411-1-bhe@redhat.com> In-Reply-To: <20180627013116.12411-1-bhe@redhat.com> From: Pavel Tatashin Date: Wed, 27 Jun 2018 13:47:28 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v5 0/4] mm/sparse: Optimize memmap allocation during sparse_init() To: bhe@redhat.com Cc: LKML , Andrew Morton , dave.hansen@intel.com, pagupta@redhat.com, Linux Memory Management List , kirill.shutemov@linux.intel.com Content-Type: text/plain; charset="UTF-8" X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8937 signatures=668703 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=3 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=633 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270189 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This work made me think why do we even have CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER ? This really should be the default behavior for all systems. Yet, it is enabled only on x86_64. We could clean up an already messy sparse.c if we removed this config, and enabled its path for all arches. We would not break anything because if we cannot allocate one large mmap_map we still fallback to allocating a page at a time the same as what happens when CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=n. Pavel