Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp1319882imm; Fri, 12 Oct 2018 16:10:35 -0700 (PDT) X-Google-Smtp-Source: ACcGV6099OBw7N3ZqKrq98z3QmjcBga3XcW9q7Dn1PlsirOPWTrFewlUYenBFQXQxLOynxOPnk49 X-Received: by 2002:a17:902:a9c8:: with SMTP id b8-v6mr7518044plr.225.1539385835367; Fri, 12 Oct 2018 16:10:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539385835; cv=none; d=google.com; s=arc-20160816; b=YtfTCT6/XWzAz0GFzNfPErHtxIBIBLneQdan1qoIrGN5y0LZlkelL0+RSzCxZqSWfM iv0PL4QegjVwKQmPAKqHpDkTdTc65KS4V60idkwb3etPJ/oJSyrNeGUte545VB4MPp2g OviGdUyW+r9S51dVBCL4sfE34Hag/M+0ljZlQw8uWaCqt2UIZmQoVxK+x7edx8mAPhDp Qva2SPp83lX/us5I895ODzWfqeLYDNdGKw8+RiN3IGZpDrPipsRuCrHEZDuUt+IOh3EI GaEhXEQYh2Oar0vbXHLzyN0FAQ9rNHtzKm3/a0A5YWFz9VQCJi+/wVmc17zySeCWg8PN 6f0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date:dkim-signature; bh=Aa7wfht1De17/v+VpkLzWV4ml0Jd7mv/a1Kf5+U9aJQ=; b=1AnH97CQmVzyQs1AWsmDfNAHjEjuOCVHSo3drVRSg53fOAK5NsbRZUo8GUQpHby71B LswK2Ipr9ErBTnV6DjGVs3Vt+XLXPYEZoCkFIDUQy+h8aAgV5xbk91BaaA4tzVRFEtSZ 6EQ08DbnNaAFS+jt4hkPdgO2MyWRZt7RGgQxFNtTUn4k/eYoDjg69J7wCkULVr0RYHW9 YboqlzezmPE9uGvFMJ8AH29zKm8vtsgfTqW9oYAQ9oj0vCDzDjWsjmKr66gofRLqJskD +iM9RRMbJs6mTOdiqn1goKFN0+sHWaR3WVzu9/FQA7lNBXYL90JfmVthAq1tTsc8rDa6 8nXg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b="ekF0eJ/W"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id w15-v6si2673963pgc.366.2018.10.12.16.10.18; Fri, 12 Oct 2018 16:10:35 -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=@google.com header.s=20161025 header.b="ekF0eJ/W"; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726026AbeJMGoh (ORCPT + 99 others); Sat, 13 Oct 2018 02:44:37 -0400 Received: from mail-pf1-f193.google.com ([209.85.210.193]:38692 "EHLO mail-pf1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725785AbeJMGoh (ORCPT ); Sat, 13 Oct 2018 02:44:37 -0400 Received: by mail-pf1-f193.google.com with SMTP id f29-v6so6899171pff.5 for ; Fri, 12 Oct 2018 16:09:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=date:from:to:cc:subject:in-reply-to:message-id:references :user-agent:mime-version; bh=Aa7wfht1De17/v+VpkLzWV4ml0Jd7mv/a1Kf5+U9aJQ=; b=ekF0eJ/WyNKcj8ssr0UJ3dwvFhHlIRlNH+rpc/ZqxDeCsjGugCfQmuW1poBNq6DZQH hD3/b0AZrwGYkoCAhho6ycCkFaXCkP60WhfCO8RNP+pU22AajWKkUXiiA2j2ILtxKHI8 YxJnq5BnDdgo+W6ESBaIUOyABblvHQNsJJeSLoQDFDfZhtEVOZQ8pDwzT7eSMWAyLVvt eq941k+S6R5nlRp6TsgcMRd8nZSvhsiJmZMKkPbgrBqXUZKpZtsEMFoVeMFKfgUGTDBc Evuqcwg9LtSR0syKTP9bEfgw4tpzL/sA2FhU80eYGkavvu1bUUemyCjFVfFgRtvUnRJF 0KHg== 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:in-reply-to:message-id :references:user-agent:mime-version; bh=Aa7wfht1De17/v+VpkLzWV4ml0Jd7mv/a1Kf5+U9aJQ=; b=cdD76uITLCFVeKy+/lc9vjobb0sSe2gELsknuJxVt0TqEZJszfSGRJcW6Qu7ZldP57 QkaAyO3rVLaY7ZsM0wf/k+cbwS9AcuXEHvlC3qPNqaLuk/cDBLC+nENYnphMn9yB07Zd zqD5mr2ELevwSTo+FOv3iWjn0tx7COS8KcEq1Brb9nBl7Rq9fowWmyKB31q7Ww4msi/A ALTD7HuPTSUjIYtmpY7/SXQRlXqzXlPsPC4tIjJpmMLSmu50Di84/buLv09TBKQi6ttj hRXhoN38W9XaG1te97WneatBTjVkZeMHeQzVr5jbG1IlX4bQBjQHhQJ6R5ygVAD5ZnGE AlqA== X-Gm-Message-State: ABuFfoiV9G6/KDl3s5Dz8jIN8/h/t70Od0vEa4mZmDbS9ktdi7SaSb0n cIjcCFtdApHhW+yrKKQCwIrOjA== X-Received: by 2002:a63:1066:: with SMTP id 38-v6mr7364710pgq.254.1539385796462; Fri, 12 Oct 2018 16:09:56 -0700 (PDT) Received: from [2620:15c:17:3:3a5:23a7:5e32:4598] ([2620:15c:17:3:3a5:23a7:5e32:4598]) by smtp.gmail.com with ESMTPSA id d2-v6sm4352808pfj.122.2018.10.12.16.09.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 12 Oct 2018 16:09:55 -0700 (PDT) Date: Fri, 12 Oct 2018 16:09:54 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Andrew Morton cc: Christoph Lameter , Pekka Enberg , Joonsoo Kim , linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [patch] mm, slab: avoid high-order slab pages when it does not reduce waste In-Reply-To: <20181012151341.286cd91321cdda9b6bde4de9@linux-foundation.org> Message-ID: References: <20181012151341.286cd91321cdda9b6bde4de9@linux-foundation.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 12 Oct 2018, Andrew Morton wrote: > > The slab allocator has a heuristic that checks whether the internal > > fragmentation is satisfactory and, if not, increases cachep->gfporder to > > try to improve this. > > > > If the amount of waste is the same at higher cachep->gfporder values, > > there is no significant benefit to allocating higher order memory. There > > will be fewer calls to the page allocator, but each call will require > > zone->lock and finding the page of best fit from the per-zone free areas. > > > > Instead, it is better to allocate order-0 memory if possible so that pages > > can be returned from the per-cpu pagesets (pcp). > > > > There are two reasons to prefer this over allocating high order memory: > > > > - allocating from the pcp lists does not require a per-zone lock, and > > > > - this reduces stranding of MIGRATE_UNMOVABLE pageblocks on pcp lists > > that increases slab fragmentation across a zone. > > Confused. Higher-order slab pages never go through the pcp lists, do > they? Nope. > I'd have thought that by tending to increase the amount of > order-0 pages which are used by slab, such stranding would be > *increased*? > These cpus have MIGRATE_UNMOVABLE pages on their pcp list. But because they are order-1 instead of order-0, we take zone->lock and find the smallest possible page in the zone's free area that is of sufficient size. On low on memory situations, there are no pages of MIGRATE_UNMOVABLE migratetype at any order in the free area. This calls __rmqueue_fallback() that steals pageblocks, MIGRATE_RECLAIMABLE and then MIGRATE_MOVABLE, and as MIGRATE_UNMOVABLE. We rely on the pcp batch count to backfill MIGRATE_UNMOVABLE pages onto the pcp list so we don't need to take zone->lock, and as a result of these allocations being order-0 rather than order-1 we can then allocate from these pages when such slab caches are expanded rather than stranding them. We noticed this when the amount of memory wasted for TCPv6 was the same for both order-0 and order-1 allocations (order-1 waste was two times the order-0 waste). We had hundreds of cpus with pages on their MIGRATE_UNMOVABLE pcp list, but while allocating order-1 memory it would prefer to happily steal other pageblocks before calling reclaim and draining pcp lists. > > We are particularly interested in the second point to eliminate cases > > where all other pages on a pageblock are movable (or free) and fallback to > > pageblocks of other migratetypes from the per-zone free areas causes > > high-order slab memory to be allocated from them rather than from free > > MIGRATE_UNMOVABLE pages on the pcp. > > > > mm/slab.c | 15 +++++++++++++++ > > Do slub and slob also suffer from this effect? > SLOB should not, SLUB will typically increase the order to improve performance of the cpu cache; there's a drawback to changing out the cpu cache that SLAB does not have. In the case that this patch is addressing, there is no greater memory utilization from the allocted slab pages.