From patchwork Tue Feb 20 21:45:57 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sourav Panda X-Patchwork-Id: 13564579 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 2C692C48BC4 for ; Tue, 20 Feb 2024 21:46:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 445ED6B006E; Tue, 20 Feb 2024 16:46:03 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3F6DB6B0071; Tue, 20 Feb 2024 16:46:03 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BD386B0072; Tue, 20 Feb 2024 16:46:03 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 1BB176B006E for ; Tue, 20 Feb 2024 16:46:03 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id AFB67140891 for ; Tue, 20 Feb 2024 21:46:02 +0000 (UTC) X-FDA: 81813515364.03.639F992 Received: from mail-yb1-f202.google.com (mail-yb1-f202.google.com [209.85.219.202]) by imf08.hostedemail.com (Postfix) with ESMTP id 099CE160005 for ; Tue, 20 Feb 2024 21:46:00 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=k3saR1GC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of 3lx3VZQsKCFwMIOL4PJ4H74AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--souravpanda.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3lx3VZQsKCFwMIOL4PJ4H74AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--souravpanda.bounces.google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708465561; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=V01TnE5q7SHBZ8jNobegTNpx6Z7xiHdfszo2NROYfag=; b=PrV1r+tjFd0GiQZCEb7cWbO6EDCNy56G3CT1zsLOQAFhzuiXsHg7DHTD1XgClz1zkFtByw vEdAtF809n11JyMPNB7nJKuOgOiPYZd76jFHbe1hzg6kUhvpXauec8PnwVlhT01MS6svxP 00o4KZJ0+/Wn4dwZSf/h2agUk45YPRY= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=k3saR1GC; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf08.hostedemail.com: domain of 3lx3VZQsKCFwMIOL4PJ4H74AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--souravpanda.bounces.google.com designates 209.85.219.202 as permitted sender) smtp.mailfrom=3lx3VZQsKCFwMIOL4PJ4H74AIIAF8.6IGFCHOR-GGEP46E.ILA@flex--souravpanda.bounces.google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708465561; a=rsa-sha256; cv=none; b=fOGwhtGhBuUj1Y6EGTHmusF57ejvVPeWzQoVpX25DQGKroNsca0L3CWVsQSP5T5Z1aoqXX ubp/8+3RqVA0/pXuBYv1jG8IU3sAUNnc7uCy5YCDZHfQ+oB8Vk9H/6S6BbX9FlNDZp0axu lvhGBJqLPfmqQkCJrmn0/HVkzpdl9Ks= Received: by mail-yb1-f202.google.com with SMTP id 3f1490d57ef6-dc746178515so9783655276.2 for ; Tue, 20 Feb 2024 13:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708465560; x=1709070360; darn=kvack.org; h=to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=V01TnE5q7SHBZ8jNobegTNpx6Z7xiHdfszo2NROYfag=; b=k3saR1GCrMa5zPZJr8W4IDRo2nkSa/n+FvAQlkLcmA4HvYaVnG3H6Zj+vV2iWWM+Ei g5cx0ZXMxSjTvGaz5oZBvnOIOn0tCmM0Ow8/Cz0Kehoj0jQWzUvANxY2PavE98EyPgXf kchm+U9d+5Sw6qrWx98XZ7FZ2hHn6pNREkCG47eej540iCeICsZajzcROFFlO0+5O0Uj lLxbp5W0rU3KyBTh0r0C57nDTIczDH487r4ThOm8wSJhi/M9DJB/Ye1cUr2CsjTdnzs+ EEfKTb0UgFPKzoNUcBm4YLTich26QmB9V+jqZ19KnF/UDS3ul+3UeigMgJNVRMBjAfqK B7Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708465560; x=1709070360; h=to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=V01TnE5q7SHBZ8jNobegTNpx6Z7xiHdfszo2NROYfag=; b=onwlt0hznsuh8R/2L5jB9205Je4MXDBqoraCDR93ObYJZzmhso03KGpalfBb+NN8od ZqzdUhAZ7PVLSKs2EONyhHK0igFMTCFnZ0hbUmtvK5usF6QmDY+uUiUCofyosgFXNLC8 D9SsrdJWiuUEemxcSuaZ7q1VmVoDEJ9w80yoV5cgHDEdBn0fUQY9XYlOgi/SEoSL7mXv LJgQuVfErBYUyNMHblTRI1eJKNIJPNHKlb1hUm3k0womGcPa92jkc8xnfNII9IREIVDs FhXcIMXvlgfCnM5Q4lj1xOHLsGDyLGpwlDQTj8yIxt4C7c0bhrFdL7rbFayOvMCwU71y bhrQ== X-Forwarded-Encrypted: i=1; AJvYcCUcCiH0GgtFq84GAGKoDdSgv77Mnkz0ASvobnHQzltjjVk+F8bsZR/t78GWSdsUdojWyshZIw6ys+M1LjVTAlzdDW4= X-Gm-Message-State: AOJu0YybH8IQ4/KMKPaxmntKDjC9ngVNBaMgznPUiglGbIgu6fqsZot2 Y8TlNRot8WHn83WkKy/btuNxZCGDVf0x+SD2k+8+Eufz4W1O3v5tiDf1sUL5xadS5aXJ0Pu92Fh cNa33V2oss5FxKLhkIN1tiw== X-Google-Smtp-Source: AGHT+IH4H1DQSgpPoUZE2eyOpZm0nIku1G5H6MYamCUomiBfTKrC+pL+XA4Rdc4IJs0x5KdY2LRkekHD7/JwALiSXw== X-Received: from souravpanda.svl.corp.google.com ([2620:15c:2a3:200:908a:1ef7:e79e:3cf5]) (user=souravpanda job=sendgmr) by 2002:a25:dbc6:0:b0:dc6:e5d3:5f03 with SMTP id g189-20020a25dbc6000000b00dc6e5d35f03mr4066041ybf.4.1708465559994; Tue, 20 Feb 2024 13:45:59 -0800 (PST) Date: Tue, 20 Feb 2024 13:45:57 -0800 Mime-Version: 1.0 X-Mailer: git-send-email 2.44.0.rc0.258.g7320e95886-goog Message-ID: <20240220214558.3377482-1-souravpanda@google.com> Subject: [PATCH v9 0/1] mm: report per-page metadata information From: Sourav Panda To: corbet@lwn.net, gregkh@linuxfoundation.org, rafael@kernel.org, akpm@linux-foundation.org, mike.kravetz@oracle.com, muchun.song@linux.dev, rppt@kernel.org, david@redhat.com, rdunlap@infradead.org, chenlinxuan@uniontech.com, yang.yang29@zte.com.cn, souravpanda@google.com, tomas.mudrunka@gmail.com, bhelgaas@google.com, ivan@cloudflare.com, pasha.tatashin@soleen.com, yosryahmed@google.com, hannes@cmpxchg.org, shakeelb@google.com, kirill.shutemov@linux.intel.com, wangkefeng.wang@huawei.com, adobriyan@gmail.com, vbabka@suse.cz, Liam.Howlett@Oracle.com, surenb@google.com, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, willy@infradead.org, weixugc@google.com X-Rspamd-Queue-Id: 099CE160005 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: f65ycs4fd1sg7pgc8m3fqpqo3oxi4i3o X-HE-Tag: 1708465560-723449 X-HE-Meta: U2FsdGVkX1/Kn/r2Jf4EAlEw5CZc7bWbFaw1s0SMD3it5tizqpzmcXisX+lMhvq4sV6qx+kDFy/7OeDKrWDWkcLzYdAhr3vZDOoMYRDqc0kYMg9VvmFo9Mo8z04YsKSD09E+H5ZVpHVzoEPEfKl17ncaPnEIG1+kW4C3xV4eThsXRdwhH4PdFeOS79ZCtK6QcA9bHPpkLwH9z9A9txjpusmLBXYA535BY6rdFcBtG7ee7AtA691JRna3QsAYaFtwuCmgbvj4IayTiW28Ijwluy9xFTPhw6J+mVdhrcHmokKQL+KpD6PBN9znDIZnnVeMoxHtMwE6TQpCaRX3ymMf25nXqNuVNYctVtFXggVadSBPhklsJ3aIKAglhu0iIWOYhlMs7pY6J/OBHCu863i7HQprtmBJkA9dWgNKpx5tN6RaSZ+60BXgZdx1WBsSoYCuUibB7RtiZ6tdlMvIb9pmVc8ATSWUjsXa+VI8y2YNP3MJaZMH/lwTphVN81nIrM7fpyc3rd7dpvwiEPwmbIkzVF6dxzyTT4vwITT2uHzMeTIQc88yTwcfw1zgbDTgmtXevJtNc33VAwF/PZFhqrDX9erwa2UrxeCg5Y4ooy6q6AOGoXCPpyER34K3gPmommiNiRWxEQvvuukGcJ0G523XPeaOZ8vd2yINQOvn61pELAvsKVTrZXsELLIrUh52GchE1jmSx3/bmjwjF880ea1Kg4DBGFQB3OaosY6nMPVhKY49iN5/lt0ob/puStLBb/08OxNfXARxWVcY1Z8HsU55+YLFIPHGVzcuf6DuC0lxUEhi4klL8ThH26pa3pSI4sf/CtKwv191EvJZFTuOA3KN/vdM0bLe3pZFph5sIeRVRbxRikM/Q3fg3rnNungorbzfoBAaCYzIr5TVxxMWyFzncrFK4VTyuFX9S/8eQ1B8wIsi0+Gi7wLAIliscu2ddOkKMtS6R3txZ2sfjrN3cWT 7kXH/FBH Ym25Peev1tCHs0DCY7krHrcX5HLleZIofmodUOi8PxhpZwRhkKMS5LMisK7nC6Hh/p42itUgQe6Cs2I5vZRw8uXinxdxAzjewm9poF0CRLhe/DDU8MuWH6VbcQjcAVvkKPJTw57CyDcEgfA5PrEFlA5vwNqppA/6T4ZsR2ihOQcNksqkGrhSbJhJls2Vf/UBP7x53IKjq0qDY5NA9FFelJ8Z9yB9S7PKxqnVLyLQDtuFZizfqKyEWV4guaSNNg4GyAxECyPuzZ2HeJUzvzwZldi6yAkcjLMqISJYIIlJ+D9UfMj76idA8KeibaT8s+SIkseNDcDIjGnnt/uqH7ytN8Vuk3IEsuM+7hLbjBdYFyqvfvDTKt+riE2VloqLrh2V2+wZ4W+q59r3ZgMwsi3roFhUViKzwQ+eMP7bxPiGOxoXlFntvzWV2ObTN4T6tS62v2HjVJ8gQ7U2Qnyekwl5cYCI+kQH1zPXf/6xHDc2b3aKPQCZlIHlge8AKU8u03k710W7AR/rkqzgWJZGlc1Uqc1NcE5Fr/1Qq+XIrigZITfcUwChmqU6EzaNMHHUVO3asVeEFKbn3acEVug1wSkqhGJ7qgGcc3D7hOhBS7hQsXO6MV2pb0NMV2SH3HEKNo2p7GgXA7O1RUNpvc9Snl/4w5osiaERMBeTRV9GCZk4209RXruMUsgJ0ZgoXODNv7MjDf5zmC3/zmL/uT1Y9s7nb49JULK+Oe3zHIeT73WU6yyj1vsTWv7Avhq7iDYZ0hVwIpGRM/uo2a0cOjK4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Changelog: v9: - Quick Fix: - In fs/proc/meminfo.c, replaced tabs with spaces for consistent userspace parsing. - Patch is ready to be taken in. v8: - Addressed Powerpc (Power8 LE) boot failure. - In __populate_section_memmap instead of calling mod_node_page_state (unavaialable at boot for powerpc), we call mod_node_early_perpage_metadata. This was a helper function that was introduced for arm, to combat this exact problem. - Since __populate_section_memmap is tagged with __meminit, we also had to modify the tag of mod_node_early_perpage_metadata from __init to __meminit. - Naming Changes: - In /proc/meminfo PageMetadata --> Memmap - In /proc/vmstat nr_page_metadata --> nr_memmap - In /proc/vmstat nr_page_metadata_boot --> nr_memmap_boot - Addressed clarifications requested by Andrew Morton. - Updated the commit log to include utility or potential usage for userspace. - Declined changing placement of metrics after attempting: - No changes in /proc/meminfo since it cannot be moved to the end anyway. This is because we have also hugetlb_report_meminfo() and arch_report_meminfo(). - Rebased to version 6, patchlevel 8. v7: - Addressed comments from David Rientjes - For exporting PageMetadata to /proc/meminfo, utilize global_node_page_state_pages for item NR_PAGE_METADATA. This is instead of iterating over nodes and accumulating the output of node_page_state. v6: - Interface changes - Added per-node nr_page_metadata and nr_page_metadata_boot fields that are exported in /sys/devices/system/node/nodeN/vmstat - nr_page_metadata exclusively tracks buddy allocations while nr_page_metadata_boot exclusively tracks memblock allocations. - Modified PageMetadata in /proc/meminfo to only include buddy allocations so that it is comparable against MemTotal in /proc/meminfo - Removed the PageMetadata field added in /sys/devices/system/node/nodeN/meminfo - Addressed bugs reported by the kernel test bot. - All occurences of __mod_node_page_state have been replaced by mod_node_page_state. - Addressed comments from Muchun Song. - Removed page meta data accouting from mm/hugetlb.c. When CONFIG_SPARSEMEM_VMEMMAP is disabled struct pages should not be returned to buddy. - Modified the cover letter with the results and analysis - From when memory_hotplug.memmap_on_memory is alternated between 0 and 1. - To account for the new interface changes. v5: - Addressed comments from Muchun Song. - Fixed errors introduced in v4 when CONFIG_SPARSEMEM_VMEMMAP is disabled by testing against FLATMEM and SPARSEMEM memory models. - Handled the condition wherein the allocation of walk.reuse_page fails, by moving NR_PAGE_METADATA update into the clause if( walk.reuse_page ). - Removed the usage of DIV_ROUND_UP from alloc_vmemmap_page_list since "end - start" is always a multiple of PAGE_SIZE. - Modified alloc_vmemmap_page_list to update NR_PAGE_METADATA once instead of every loop. v4: - Addressed comment from Matthew Wilcox. - Used __node_stat_sub_folio and __node_stat_add_folio instead of __mod_node_page_state in mm/hugetlb.c. - Used page_pgdat wherever possible in the entire patch. - Used DIV_ROUND_UP() wherever possible in the entire patch. v3: - Addressed one comment from Matthew Wilcox. - In free_page_ext, page_pgdat() is now extracted prior to freeing the memory. v2: - Fixed the three bugs reported by kernel test robot. - Enhanced the commit message as recommended by David Hildenbrand. - Addressed comments from Matthew Wilcox: - Simplified alloc_vmemmap_page_list() and free_page_ext() as recommended. - Used the appropriate comment style in mm/vmstat.c. - Replaced writeout_early_perpage_metadata() with store_early_perpage_metadata() to reduce ambiguity with what swap does. - Addressed comments from Mike Rapoport: - Simplified the loop in alloc_vmemmap_page_list(). - Could NOT address a comment to move store_early_perpage_metadata() near where nodes and page allocator are initialized. - Included the vmalloc()ed page_ext in accounting within free_page_ext(). - Made early_perpage_metadata[MAX_NUMNODES] static. Previous approaches and discussions ----------------------------------- V8: https://lore.kernel.org/all/20240214225741.403783-1-souravpanda@google.com V7: https://lore.kernel.org/all/20240129224204.1812062-1-souravpanda@google.com V6: https://lore.kernel.org/all/20231205223118.3575485-1-souravpanda@google.com v5: https://lore.kernel.org/all/20231101230816.1459373-1-souravpanda@google.com v4: https://lore.kernel.org/all/20231031223846.827173-1-souravpanda@google.com v3: https://lore.kernel.org/all/20231031174459.459480-1-souravpanda@google.com v2: https://lore.kernel.org/all/20231018005548.3505662-1-souravpanda@google.com v1: https://lore.kernel.org/r/20230913173000.4016218-2-souravpanda@google.com Hi! This patch adds two new per-node fields, namely nr_memmap and nr_memmap_boot to /sys/devices/system/node/nodeN/vmstat and a global Memmap field to /proc/meminfo. This information can be used by users to see how much memory is being used by per-page metadata, which can vary depending on build configuration, machine architecture, and system use. Per-page metadata is the amount of memory that Linux needs in order to manage memory at the page granularity. The majority of such memory is used by "struct page" and "page_ext" data structures. Background ---------- Kernel overhead observability is missing some of the largest allocations during runtime, including vmemmap (struct pages) and page_ext. This patch aims to address this problem by exporting a new metric Memmap. On the contrary, the kernel does provide observibility for boot memory allocations. For example, the metric reserved_pages depicts the pages allocated by the bootmem allocator. This can be simply calculated as present_pages - managed_pages, which are both exported in /proc/zoneinfo. The metric reserved_pages is primarily composed of struct pages and page_ext. What about the struct pages (allocated by bootmem allocator) that are free'd during hugetlbfs allocations and then allocated by buddy-allocator once hugtlbfs pages are free'd? /proc/meminfo MemTotal changes: MemTotal does not include memblock allocations but includes buddy allocations. However, during runtime memblock allocations can be shifted into buddy allocations, and therefore become part of MemTotal. Once the struct pages get allocated by buddy allocator, we lose track of these struct page allocations overhead accounting. Therefore, we must export new metrics. nr_memmap and nr_memmap_boot exclusively track the struct page and page ext allocations made by the buddy allocator and memblock allocator, respectively for each node. Memmap in /proc/meminfo would report the struct page and page ext allocations made by the buddy allocator. Results and analysis -------------------- Memory model: Sparsemem-vmemmap $ echo 1 > /proc/sys/vm/hugetlb_optimize_vmemmap $ cat /proc/meminfo | grep MemTotal MemTotal: 32919124 kB $ cat /proc/meminfo | grep Memmap Memmap: 65536 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 $ cat /sys/devices/system/node/node1/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 AFTER HUGTLBFS RESERVATION $ echo 512 > /proc/sys/vm/nr_hugepages $ cat /proc/meminfo | grep MemTotal MemTotal: 32935508 kB $ cat /proc/meminfo | grep Memmap Memmap: 67584 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8448 nr_memmap_boot 63488 $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8448 nr_memmap_boot 63488 AFTER FREEING HUGTLBFS RESERVATION $ echo 0 > /proc/sys/vm/nr_hugepages $ cat /proc/meminfo | grep MemTotal MemTotal: 32935508 kB $ cat /proc/meminfo | grep Memmap Memmap: 81920 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 10240 nr_memmap_boot 63488 $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 10240 nr_memmap_boot 63488 ------------------------ Memory Hotplug with memory_hotplug.memmap_on_memory=1 BEFORE HOTADD $ cat /proc/meminfo | grep MemTotal MemTotal: 32919124 kB $ cat /proc/meminfo | grep Memmap Memmap: 65536 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 AFTER HOTADDING 1GB $ cat /proc/meminfo | grep MemTotal MemTotal: 33951316 kB $ cat /proc/meminfo | grep Memmap Memmap: 83968 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 12800 nr_memmap_boot 65536 $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 -------------------------- Memory Hotplug with memory_hotplug.memmap_on_memory=0 BEFORE HOTADD $ cat /proc/meminfo | grep MemTotal MemTotal: 32919124 kB $ cat /proc/meminfo | grep Memmap Memmap: 65536 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 AFTER HOTADDING 1GB $ cat /proc/meminfo | grep MemTotal MemTotal: 33967700 kB $ cat /proc/meminfo | grep Memmap Memmap: 83968 kB $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 12800 nr_memmap_boot 65536 $ cat /sys/devices/system/node/node0/vmstat | grep "nr_memmap" nr_memmap 8192 nr_memmap_boot 65536 Sourav Panda (1): mm: report per-page metadata information Documentation/filesystems/proc.rst | 3 +++ fs/proc/meminfo.c | 4 ++++ include/linux/mmzone.h | 4 ++++ include/linux/vmstat.h | 4 ++++ mm/hugetlb_vmemmap.c | 17 ++++++++++++---- mm/mm_init.c | 3 +++ mm/page_alloc.c | 1 + mm/page_ext.c | 32 +++++++++++++++++++++--------- mm/sparse-vmemmap.c | 8 ++++++++ mm/sparse.c | 7 ++++++- mm/vmstat.c | 26 +++++++++++++++++++++++- 11 files changed, 94 insertions(+), 15 deletions(-)