Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp1445599imm; Thu, 19 Jul 2018 01:37:02 -0700 (PDT) X-Google-Smtp-Source: AAOMgpcAor2HkIHbclLFPdyP6m5fFyBAoM4UdVFOgIIfUGG3vPGD/Xri7KAOA/xw3utKZx52n82P X-Received: by 2002:a63:5660:: with SMTP id g32-v6mr9207812pgm.227.1531989421963; Thu, 19 Jul 2018 01:37:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531989421; cv=none; d=google.com; s=arc-20160816; b=wg18cft474qrcI8DNrn1LhikJfed7cvRdRMTu0NPqlasA0GwmkEB1AzBRWbYP47Lbv 8o+jVCiMQ2hwN4DxiahP2f9izH04JE1kpn3RodZGa/RBtISkizq5zYbUG82ObbSMSApc sjN9rvc1ySmkvH798yo+Pq9HMBqS4TtQ5Or2N1+lVlwLjRZU/Q4m0OuQaqlw9MTL9MuW G6NCUgsyj4cjxkwtH/Mi7v/2z64IQ9K3EeL3NCjQV3QjsZsfZ259fQ5D3X+kufHbVwv2 lgWiRhBdWUpSKJSD8olTraO/2OFdGjmm1KW1pHjIEoOQNeIhKiHXXTPejQEtbTo3WdSW PGHg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=dKlVFGItQbEyCpoSOOC/dxGigoV9J0eHY/WQUVO2j2w=; b=heheuIaVTq39aqmIkAXBQRh5RE1d7BmYtZnpwGv+0TDX7rjh6MWBoqM1eCy8MfJOoX xcaLi7Ix5fZ50ezXuX13WRLm53JTUEVAlJHYeq+S2dvsf3azzL6mqzBjMAlrV+mZjxs0 Vvon+EiAVChvf5182XfwrfPrfBLZM3dMF9t2o113pQBHASEPErkGS9AcYj/bwt4gWgPK vale47P/mSGO9iuEMMToTQ339r8Pcyj6It+qXFSSF7GxrdFL+yJpD7TVn5NwKCQZKi38 qzFhtDAdUoUzS955RcVpOcouXCIG/dLt6polE/heAzoKSyhLyY6jiA1TnnEXFm73hpEg rXxQ== 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 v37-v6si5174152plg.486.2018.07.19.01.36.47; Thu, 19 Jul 2018 01:37:01 -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 S1730429AbeGSJRg (ORCPT + 99 others); Thu, 19 Jul 2018 05:17:36 -0400 Received: from outbound-smtp27.blacknight.com ([81.17.249.195]:52442 "EHLO outbound-smtp27.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727706AbeGSJRg (ORCPT ); Thu, 19 Jul 2018 05:17:36 -0400 Received: from mail.blacknight.com (pemlinmail01.blacknight.ie [81.17.254.10]) by outbound-smtp27.blacknight.com (Postfix) with ESMTPS id BD51FB8760 for ; Thu, 19 Jul 2018 09:35:31 +0100 (IST) Received: (qmail 22801 invoked from network); 19 Jul 2018 08:35:31 -0000 Received: from unknown (HELO techsingularity.net) (mgorman@techsingularity.net@[37.228.237.66]) by 81.17.254.9 with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 19 Jul 2018 08:35:31 -0000 Date: Thu, 19 Jul 2018 09:35:30 +0100 From: Mel Gorman To: Vlastimil Babka Cc: Andrew Morton , 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 , Matthew Wilcox Subject: Re: [PATCH v3 3/7] mm, slab: allocate off-slab freelists as reclaimable when appropriate Message-ID: <20180719083530.jhugqzkvjnbrddim@techsingularity.net> References: <20180718133620.6205-1-vbabka@suse.cz> <20180718133620.6205-4-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20180718133620.6205-4-vbabka@suse.cz> User-Agent: NeoMutt/20170912 (1.9.0) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jul 18, 2018 at 03:36:16PM +0200, Vlastimil Babka wrote: > In SLAB, OFF_SLAB caches allocate management structures (currently just the > freelist) from kmalloc caches when placement in a slab page together with > objects would lead to suboptimal memory usage. For SLAB_RECLAIM_ACCOUNT caches, > we can allocate the freelists from the newly introduced reclaimable kmalloc > caches, because shrinking the OFF_SLAB cache will in general result to freeing > of the freelists as well. This should improve accounting and anti-fragmentation > a bit. > > Signed-off-by: Vlastimil Babka I'm not quite convinced by this one. The freelist cache is tied to the lifetime of the slab and not the objects. A single freelist can be reclaimed eventually but for caches with many objects per slab, it could take a lot of shrinking random objects to reclaim one freelist. Functionally the patch appears to be fine. -- Mel Gorman SUSE Labs