Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp2860893imm; Tue, 4 Sep 2018 11:08:35 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaCVcvxCEWbSalEr5owsRijWmh8NyoZRNtUsXx10FEy7LzzvShEv78mzSJLxGt3X9JFtZvy X-Received: by 2002:a63:7b1d:: with SMTP id w29-v6mr9939351pgc.249.1536084514957; Tue, 04 Sep 2018 11:08:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536084514; cv=none; d=google.com; s=arc-20160816; b=MFNQqQsmbP8/JyG8mYPWC13fqDpRs16k04i1+V9O8cO0J9V57l18ZwO9HKrbmz5xX7 DgunZXtDemLjNQauRCJexHeVwt4BhbzYXKR30536dJCJ4OLlaU1lvNox/Vj6Em2q0uiv hL3pPL5h1JIVRIupzlICJxyn2hM8GVCwqYJ7JzoiOQ06alChcysCSqeaDjsTBhHyKIN/ V7NvL8plxWQkSK7tWEDdByvz8L2Z2LzrgItcNTM9drtSiZ1wGQEdrCl/DU/yF8tX81AQ xHBjhFeX8ipAobE5v+e2EuS0HV/sgCfy/27WMBx72foJMK+uG5JrJPdU7eHSUNL46g4H NsfA== 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=QCcCUiVC5a+Wi3Ep0j0G5cJ80ZLdgMWvBA5mNpQ6FDA=; b=rnLxf5ilnIHSs/Miv9650f+88r+8UOkyFeYRB5P2yqem+5jXH/lgaOof9REtVfTgem 1GZCbyxKTGDoP2JPZAVULIG80MfPbLk3vJq4b+EpdET5WRuZq7dEp014kKDSeQsyzZGt ghRd/XnZfkyet6cG6gOvgof9/nUURAptk9AbVzKgK+9o7Y82GGPfJF8JKRHP1aJxSblV KRGbz+xPPrhh/J2m+eyeUINS4btQblxU84qca9J3raBjKx7UaQ6J/8mzZJTz6zu4EEii ipYusH3FJ15XWYKgEqs6GR/026ZoSKdxChpk/sRtrbHrnvutrZ8LkXCK8uXi3kyX5gNy v9Aw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r23-v6si22849392pfr.252.2018.09.04.11.08.18; Tue, 04 Sep 2018 11:08:34 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727781AbeIDWcs (ORCPT + 99 others); Tue, 4 Sep 2018 18:32:48 -0400 Received: from mx2.suse.de ([195.135.220.15]:48646 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726437AbeIDWcs (ORCPT ); Tue, 4 Sep 2018 18:32:48 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id F10F4B0B4; Tue, 4 Sep 2018 18:06:33 +0000 (UTC) Date: Tue, 4 Sep 2018 20:06:31 +0200 From: Michal Hocko To: Roman Gushchin Cc: Rik van Riel , linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel-team@fb.com, Josef Bacik , Johannes Weiner , Andrew Morton Subject: Re: [PATCH] mm: slowly shrink slabs with a relatively small number of objects Message-ID: <20180904180631.GR14951@dhcp22.suse.cz> References: <20180831203450.2536-1-guro@fb.com> <3b05579f964cca1d44551913f1a9ee79d96f198e.camel@surriel.com> <20180831213138.GA9159@tower.DHCP.thefacebook.com> <20180903182956.GE15074@dhcp22.suse.cz> <20180903202803.GA6227@castle.DHCP.thefacebook.com> <20180904070005.GG14951@dhcp22.suse.cz> <20180904153445.GA22328@tower.DHCP.thefacebook.com> <20180904161431.GP14951@dhcp22.suse.cz> <20180904175243.GA4889@tower.DHCP.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180904175243.GA4889@tower.DHCP.thefacebook.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue 04-09-18 10:52:46, Roman Gushchin wrote: > On Tue, Sep 04, 2018 at 06:14:31PM +0200, Michal Hocko wrote: [...] > > I am not opposing your patch but I am trying to figure out whether that > > is the best approach. > > I don't think the current logic does make sense. Why should cgroups > with less than 4k kernel objects be excluded from being scanned? How is it any different from the the LRU reclaim? Maybe it is just not that visible because there usually more pages there. But in principle it is the same issue AFAICS. > Reparenting of all pages is definitely an option to consider, > but it's not free in any case, so if there is no problem, > why should we? Let's keep it as a last measure. In my case, > the proposed patch works perfectly: the number of dying cgroups > jumps around 100, where it grew steadily to 2k and more before. Let me emphasise that I am not opposing the patch. I just think that we have made some decisions which are not ideal but I would really like to prevent from building workarounds on top. If we have to reconsider some of those decisions then let's do it. Maybe the priority scaling is just too coarse and what seem to work work for normal LRUs doesn't work for shrinkers. > I believe that reparenting of LRU lists is required to minimize > the number of LRU lists to scan, but I'm not sure. Well, we do have more lists to scan for normal LRUs. It is true that shrinkers add multiplining factor to that but in principle I guess we really want to distinguish dead memcgs because we do want to reclaim those much more than the rest. Those objects are basically of no use just eating resources. The pagecache has some chance to be reused at least but I fail to see why we should keep kernel objects around. Sure, some of them might be harder to reclaim due to different life time and internal object management but this doesn't change the fact that we should try hard to reclaim those. So my gut feeling tells me that we should have a way to distinguish them. Btw. I do not see Vladimir on the CC list. Added (the thread starts here http://lkml.kernel.org/r/20180831203450.2536-1-guro@fb.com) -- Michal Hocko SUSE Labs