From patchwork Tue Jul 31 09:06:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vlastimil Babka X-Patchwork-Id: 10550485 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 1B1BE13BF for ; Tue, 31 Jul 2018 09:07:05 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 084F729FB4 for ; Tue, 31 Jul 2018 09:07:05 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id F080E2A206; Tue, 31 Jul 2018 09:07:04 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.0 tests=BAYES_00,MAILING_LIST_MULTI, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 705A129FB4 for ; Tue, 31 Jul 2018 09:07:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 47DB56B0269; Tue, 31 Jul 2018 05:07:03 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 454246B026A; Tue, 31 Jul 2018 05:07:03 -0400 (EDT) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3363F6B0269; Tue, 31 Jul 2018 05:07:03 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from mail-pl0-f71.google.com (mail-pl0-f71.google.com [209.85.160.71]) by kanga.kvack.org (Postfix) with ESMTP id E43366B000C for ; Tue, 31 Jul 2018 05:07:02 -0400 (EDT) Received: by mail-pl0-f71.google.com with SMTP id 31-v6so10942622pld.6 for ; Tue, 31 Jul 2018 02:07:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-original-authentication-results:x-gm-message-state:from:to:cc :subject:date:message-id; bh=lykwiIL3K5R64QefRHkguKCjGhSXfe1J3b/47DGhFzI=; b=B/lj5jky5jk7GAKUyGdlehq/5PIfND/HnHBBmsIj/VgcNNceomAGt9tNnXkJxL8YAO uIQlQZeGDYESFrT07lscnl51coQfxu67z9dVl4Do02XzPz5fl8E2W+Wp5oY1HXEKL/0M f96AqTXZ1VQN2JebwpP6eIpI++37QLa/DA9Ak+UFjogQZK4ISx4g/hrIxZODj5XGBowY 618cdIEWKDXpkhpa4ur/5F3vTHFsc4Noeydz78e3hmqrt4Sso9om5SvUCG8cb9+zTGVU uM9YBxUNxMtcQrIBfHu9Zhi7XwnHB/8TihEYeU3UDl9l4FZi7HPsBgGw1TFoFUKew9kO LohQ== X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of vbabka@suse.cz designates 195.135.220.15 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Gm-Message-State: AOUpUlGTTXtPTIe16tDBWXv+T8+4pMgu4piUDo9basy+nwxIQfca6AJ6 4CYAdh52iAEqB1K7OBMFlXj/zvBQZUFKuVe3ncRU9Asgfx1hCRFjvGXIva5h2d8T/uzBPH/19AQ rTEDNvxeOZb7tR03Oad4HUKoEY2YGXNmWnMw3+TjnSoxiFx145TZ9H5qReIG3C08v0A== X-Received: by 2002:a17:902:7088:: with SMTP id z8-v6mr10625257plk.303.1533028022582; Tue, 31 Jul 2018 02:07:02 -0700 (PDT) X-Google-Smtp-Source: AAOMgpd5S73nTqTO6J1lfqxHuKSo5oPmETxw/VjDjlKP2qNtO+bkvzNSR7XduzQhj+GMIpotjFUj X-Received: by 2002:a17:902:7088:: with SMTP id z8-v6mr10625216plk.303.1533028021763; Tue, 31 Jul 2018 02:07:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533028021; cv=none; d=google.com; s=arc-20160816; b=b/Bos2EdD/jE6KSS93eaqF43PqwDJ3gvAAC8ktsXeO/+mStzlhdsPB+1GNQOhxL5nm QvrWMrze3ntvzy9kksvCJy2Had0q2XF0MxGVklglc5RzBBj0G2ncqVVMXE82F4hdGH+O /VJhGwsH1Tevz7AmpBykikX6HcjtNEhzolI4w+ebxy9uw2Wu1fIk5ufNGRr8BqiRyYqm 1Yeb7R9Smy3rfIaqmtWmLjNfMvyfmKg3DWn/a4HoBUi0OjXmtyYgqGtV2eXXpPN9fnqw uv4+ISdQr1heg6ZjKLnxdhfHc78RoRHkiSHZv5xQHMzGOBh5dVGAIeh/ECo8nQcSqOWj aceg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:arc-authentication-results; bh=lykwiIL3K5R64QefRHkguKCjGhSXfe1J3b/47DGhFzI=; b=YNVLla0nWsrY3p9aEAexVGh1ztrFzxqjQl+YNPL/KdnvN+hrclpanuMA1YiV6QMhOX sWl0O0VcY4A1rm8HMjv+pGBFYpt29Cigu/ZABLJJQNSGTz0Qs0OORMyrRzqRcKtj2flR 9CROkMtIFK/NfGqdUsFucRYaYi8kyl28VwUnX7QHjA09IEs3ja2427OjKaLxhlQnHdpj lzMMCy7KlD00NpHZbcqxFSTTDWJ/cf7uyoRmkhIDKbRKcPew+nngpWxG8PQmpS6kEvyE tBcloySQJxHz9EsGv0cg9549DIW+jNZQQGrbbyUh4LRM77eWHD36BJ5iEPdxvwbIfGn6 oDgA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of vbabka@suse.cz designates 195.135.220.15 as permitted sender) smtp.mailfrom=vbabka@suse.cz Received: from mx1.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id 6-v6si12326820pgz.592.2018.07.31.02.07.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jul 2018 02:07:01 -0700 (PDT) Received-SPF: pass (google.com: domain of vbabka@suse.cz designates 195.135.220.15 as permitted sender) client-ip=195.135.220.15; Authentication-Results: mx.google.com; spf=pass (google.com: domain of vbabka@suse.cz designates 195.135.220.15 as permitted sender) smtp.mailfrom=vbabka@suse.cz X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8C9D1AE0E; Tue, 31 Jul 2018 09:06:58 +0000 (UTC) From: Vlastimil Babka To: Andrew Morton Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Roman Gushchin , Michal Hocko , Johannes Weiner , Christoph Lameter , David Rientjes , Joonsoo Kim , Mel Gorman , Matthew Wilcox , Vlastimil Babka , Laura Abbott , Sumit Semwal , Vijayanand Jitta Subject: [PATCH v4 0/6] kmalloc-reclaimable caches Date: Tue, 31 Jul 2018 11:06:43 +0200 Message-Id: <20180731090649.16028-1-vbabka@suse.cz> X-Mailer: git-send-email 2.18.0 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: X-Virus-Scanned: ClamAV using ClamSMTP v4 changes: - drop mm, slab: allocate off-slab freelists as reclaimable when appropriate - per Mel, reclaiming objects from a slab doesn't guarantee that the whole slab page will be freed and freelist reclaimed, so it can do more harm than good - change KMALLOC_* constants from #define to enum, per Christoph - use the symbolic constants in kmalloc_type(), per Roman - add acks from Mel, Roman and Christoph, thanks! v3 changes: - fix missing hunk in patch 5/7 - more verbose cover letter and patch 6/7 commit log v2 changes: - shorten cache names to kmalloc-rcl- - last patch shortens for all kmalloc caches to e.g. "1k", "4M" - include dma caches to the 2D kmalloc_caches[] array to avoid a branch - vmstat counter nr_indirectly_reclaimable_bytes renamed to nr_kernel_misc_reclaimable, doesn't include kmalloc-rcl-* - /proc/meminfo counter renamed to KReclaimable, includes kmalloc-rcl* and nr_kernel_misc_reclaimable Hi, as discussed at LSF/MM [1] here's a patchset that introduces kmalloc-reclaimable caches (more details in the second patch) and uses them for dcache external names. That allows us to repurpose the NR_INDIRECTLY_RECLAIMABLE_BYTES counter later in the series. With patch 3/6, dcache external names are allocated from kmalloc-rcl-* caches, eliminating the need for manual accounting. More importantly, it also ensures the reclaimable kmalloc allocations are grouped in pages separate from the regular kmalloc allocations. The need for proper accounting of dcache external names has shown it's easy for misbehaving process to allocate lots of them, causing premature OOMs. Without the added grouping, it's likely that a similar workload can interleave the dcache external names allocations with regular kmalloc allocations (note: I haven't searched myself for an example of such regular kmalloc allocation, but I would be very surprised if there wasn't some). A pathological case would be e.g. one 64byte regular allocations with 63 external dcache names in a page (64x64=4096), which means the page is not freed even after reclaiming after all dcache names, and the process can thus "steal" the whole page with single 64byte allocation. If there other kmalloc users similar to dcache external names become identified, they can also benefit from the new functionality simply by adding __GFP_RECLAIMABLE to the kmalloc calls. Side benefits of the patchset (that could be also merged separately) include removed branch for detecting __GFP_DMA kmalloc(), and shortening kmalloc cache names in /proc/slabinfo output. The latter is potentially an ABI break in case there are tools parsing the names and expecting the values to be in bytes. This is how /proc/slabinfo looks like after booting in virtme: ... kmalloc-rcl-4M 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 ... kmalloc-rcl-96 7 32 128 32 1 : tunables 120 60 8 : slabdata 1 1 0 kmalloc-rcl-64 25 128 64 64 1 : tunables 120 60 8 : slabdata 2 2 0 kmalloc-rcl-32 0 0 32 124 1 : tunables 120 60 8 : slabdata 0 0 0 kmalloc-4M 0 0 4194304 1 1024 : tunables 1 1 0 : slabdata 0 0 0 kmalloc-2M 0 0 2097152 1 512 : tunables 1 1 0 : slabdata 0 0 0 kmalloc-1M 0 0 1048576 1 256 : tunables 1 1 0 : slabdata 0 0 0 ... /proc/vmstat with renamed nr_indirectly_reclaimable_bytes counter: ... nr_slab_reclaimable 2817 nr_slab_unreclaimable 1781 ... nr_kernel_misc_reclaimable 0 ... /proc/meminfo with new KReclaimable counter: ... Shmem: 564 kB KReclaimable: 11260 kB Slab: 18368 kB SReclaimable: 11260 kB SUnreclaim: 7108 kB KernelStack: 1248 kB ... Thanks, Vlastimil Vlastimil Babka (6): mm, slab: combine kmalloc_caches and kmalloc_dma_caches mm, slab/slub: introduce kmalloc-reclaimable caches dcache: allocate external names from reclaimable kmalloc caches mm: rename and change semantics of nr_indirectly_reclaimable_bytes mm, proc: add KReclaimable to /proc/meminfo mm, slab: shorten kmalloc cache names for large sizes Documentation/filesystems/proc.txt | 4 + drivers/base/node.c | 19 ++-- drivers/staging/android/ion/ion_page_pool.c | 8 +- fs/dcache.c | 38 ++------ fs/proc/meminfo.c | 16 +-- include/linux/mmzone.h | 2 +- include/linux/slab.h | 56 ++++++++--- mm/page_alloc.c | 19 ++-- mm/slab.c | 4 +- mm/slab_common.c | 103 ++++++++++++-------- mm/slub.c | 13 +-- mm/util.c | 3 +- mm/vmstat.c | 6 +- 13 files changed, 163 insertions(+), 128 deletions(-)