Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1984007imm; Thu, 24 May 2018 04:02:29 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpflV82xtskAqpai7nAL9TZ+S7DkGKwG1LkDWvZYoLVIQTc1JcCLmUPimUmksLplxEnPQ++ X-Received: by 2002:a17:902:341:: with SMTP id 59-v6mr6917665pld.324.1527159749670; Thu, 24 May 2018 04:02:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527159749; cv=none; d=google.com; s=arc-20160816; b=g44/lPwufqYHLZNXoUnlxljAdAmrT5t3+GDFhoND/SLBiYSFTPFbiAv7KKhyR5xuRe vrBDzZXbkbE6mcd7T0p/LxtoMfDIzlL0lzNPkD0x0SaO9g3gg40c69MKiwFySBIuMol1 oYt3WzeLqOMse0UzvsXTUVzq8bgbbmuHFv7kCh5rvSccINxgAwuvEoJpbNpPJVn5SWUH zl1vat/WUSfXkyVLG9OtloSduEEEvEBITYZLNWgwMeibQ/w3NmRtHZwML6/bmw0cxdcz N5wJUvypCKDrHaoxX8HrTvQMK4BQTZtUNqUFIH9CXTZRo6DBAjvGV1fZ+sitWV+mOPiF odSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=MzmMtJjvfOOGbgx/dtgBAGNsWB//sPS4H4obiJV22dQ=; b=y15517vem/Y+nmuGCIfUjhpDBuhvVQGaBj8ylTVLzFjeE+kgJpHZ6mtABzulFOIZdX yA6KjG5vUOlUoVBCdHIvHMLyvPmQ2HFHPGtpoLPCxkvlY7Lg5L00n0C0DdhQZu8bAGjc noNoHXlKRhUJAJx44r0kDLywVsWdyHH4gsLtV9TRf3S/vi+7s22y/ObBtktV2MGigbfC RU5ICrTghLO85A6uBt562BuDvJ8S6+GmC90W9aAJ41SnNeMjJ+gd/HUhTGH/hscBLLa2 cB8CG8ctmFtW4KEjpMS82EpkArhNvQUch379DEdQraIw1GMJKdKeJK45JDdP+0pNlv16 GtKg== 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 ay9-v6si22459007plb.259.2018.05.24.04.02.09; Thu, 24 May 2018 04:02:29 -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 S1032806AbeEXLBW (ORCPT + 99 others); Thu, 24 May 2018 07:01:22 -0400 Received: from mx2.suse.de ([195.135.220.15]:36185 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S967917AbeEXLA0 (ORCPT ); Thu, 24 May 2018 07:00:26 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BAB7EAF4A; Thu, 24 May 2018 11:00:23 +0000 (UTC) From: Vlastimil Babka To: linux-mm@kvack.org Cc: Roman Gushchin , Michal Hocko , Johannes Weiner , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Mel Gorman , Vijayanand Jitta , Vlastimil Babka Subject: [RFC PATCH 0/5] kmalloc-reclaimable caches Date: Thu, 24 May 2018 13:00:06 +0200 Message-Id: <20180524110011.1940-1-vbabka@suse.cz> X-Mailer: git-send-email 2.17.0 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, as discussed at LSF/MM [1] here's a RFC patchset that introduces kmalloc-reclaimable caches (more details in the first patch) and uses them for SLAB freelists and dcache external names. The latter allows us to repurpose the NR_INDIRECTLY_RECLAIMABLE_BYTES counter later in the series. This is how /proc/slabinfo looks like after booting in virtme: ... kmalloc-reclaimable-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 ... kmalloc-reclaimable-96 17 64 128 32 1 : tunables 120 60 8 : slabdata 2 2 0 kmalloc-reclaimable-64 50 128 64 64 1 : tunables 120 60 8 : slabdata 2 2 6 kmalloc-reclaimable-32 0 0 32 124 1 : tunables 120 60 8 : slabdata 0 0 0 kmalloc-4194304 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 ... kmalloc-64 2888 2944 64 64 1 : tunables 120 60 8 : slabdata 46 46 454 kmalloc-32 4325 4712 32 124 1 : tunables 120 60 8 : slabdata 38 38 563 kmalloc-128 1178 1216 128 32 1 : tunables 120 60 8 : slabdata 38 38 114 ... /proc/vmstat with new/renamed nr_reclaimable counter (patch 4): ... nr_slab_reclaimable 2817 nr_slab_unreclaimable 1781 ... nr_reclaimable 2817 ... /proc/meminfo with exposed nr_reclaimable counter (patch 5): ... AnonPages: 8624 kB Mapped: 3340 kB Shmem: 564 kB Reclaimable: 11272 kB Slab: 18368 kB SReclaimable: 11272 kB SUnreclaim: 7096 kB KernelStack: 1168 kB PageTables: 448 kB ... Now for the issues a.k.a. why RFC: - I haven't find any other obvious users for reclaimable kmalloc (yet) - the name of caches kmalloc-reclaimable-X is rather long - the vmstat/meminfo counter name is rather general and might suggest it also includes reclaimable page caches, which it doesn't Suggestions welcome for all three points. For the last one, we might also keep the counter separate from nr_slab_reclaimable, not superset. I did a superset as IIRC somebody suggested that in the older threads or at LSF. Thanks, Vlastimil [1] https://lwn.net/Articles/753154/ Vlastimil Babka (5): mm, slab/slub: introduce kmalloc-reclaimable caches mm, slab: allocate off-slab freelists as reclaimable when appropriate dcache: allocate external names from reclaimable kmalloc caches mm: rename and change semantics of nr_indirectly_reclaimable_bytes mm, proc: add NR_RECLAIMABLE to /proc/meminfo drivers/base/node.c | 2 + drivers/staging/android/ion/ion_page_pool.c | 4 +- fs/dcache.c | 40 ++++----------- fs/proc/meminfo.c | 3 +- include/linux/mmzone.h | 2 +- include/linux/slab.h | 17 +++++-- mm/page_alloc.c | 15 ++---- mm/slab.c | 23 ++++++--- mm/slab_common.c | 56 ++++++++++++++------- mm/slub.c | 12 ++--- mm/util.c | 16 ++---- mm/vmstat.c | 6 +-- 12 files changed, 99 insertions(+), 97 deletions(-) -- 2.17.0