From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7D9F6C63697 for ; Sat, 28 Nov 2020 11:47:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D8E94222E8 for ; Sat, 28 Nov 2020 11:47:25 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="fWzD9ONs" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D8E94222E8 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 0FF036B005C; Sat, 28 Nov 2020 06:47:25 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0AFF56B005D; Sat, 28 Nov 2020 06:47:25 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EE1E76B0068; Sat, 28 Nov 2020 06:47:24 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0009.hostedemail.com [216.40.44.9]) by kanga.kvack.org (Postfix) with ESMTP id D60DB6B005C for ; Sat, 28 Nov 2020 06:47:24 -0500 (EST) Received: from smtpin29.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 99C83180AD82F for ; Sat, 28 Nov 2020 11:47:24 +0000 (UTC) X-FDA: 77533651608.29.vest00_0a0bbd427390 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin29.hostedemail.com (Postfix) with ESMTP id 7677618086581 for ; Sat, 28 Nov 2020 11:47:24 +0000 (UTC) X-HE-Tag: vest00_0a0bbd427390 X-Filterd-Recvd-Size: 5713 Received: from mail-pf1-f193.google.com (mail-pf1-f193.google.com [209.85.210.193]) by imf43.hostedemail.com (Postfix) with ESMTP for ; Sat, 28 Nov 2020 11:47:23 +0000 (UTC) Received: by mail-pf1-f193.google.com with SMTP id y7so6718678pfq.11 for ; Sat, 28 Nov 2020 03:47:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=HtMqaJFJ6r3Gr7E/AkLLoq79x27VuTSfXggpQeCTzKs=; b=fWzD9ONsszHx3+IenbM+9ekCM8Gnkqs2EuE0o60ZaFsMdfYU0yz4/UApl4lm5MLpLW NuUhx1cpF2Cz0EYEVxWI4zcSOrS0pvngoYw0OCFim/iJF46iW1UEkBZHTMIxn0xuco3m gjqV4IKmyuFBhmAkNcuPN067iRSOr6TuMsKYadmOsXJ3NUl7J7kxog8dJShF9QpBT2O6 v+LK2PFXtrw7agOZzDzVrAwCifeC17wBXXawUAlwxgmAsZG9dldUunxPM9VwYp4Vh4Re +NEOi1fKCZ9r4uBe4euP72vKAsYQ0Tmw00xu47MttF7C9iGr3KCyov3wrH9QW2daTMLE KvVg== 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:message-id:references :mime-version:content-disposition:in-reply-to; bh=HtMqaJFJ6r3Gr7E/AkLLoq79x27VuTSfXggpQeCTzKs=; b=RBQTYrlQApufyzRj1w4YI0oI/oFbp1U5ZXUpoMK7aIlsExHR099KOXXEXFAf7iyxhr tE97bFcDXwi1Pahmp4ZCp1VaA06Ts9fJ/0T4HmhULBiNT+qUdbNgV7/ru4jxddKlTWqH 30neIf1jCuyaZHLn2GTIDdILIMj2FNsp0t4AC5AjtetdOf3OHXxzosa6vc8RSO4GNr/b pDNh40Wi1eqlruqjSO07Op4CsWG2e9l0+aEYYEzuznhqCTHtEewdjYrST1XlmZ9KV6lZ QeRgR26SpcJo0OgDcwVc1xDL9zhfY/Iyca6vWC2jPGWG4uiNAIoMCK4KSXfKXbN1Opl6 /SvA== X-Gm-Message-State: AOAM530sGTxwNdv2QMrl8RgzWWFDeXQAxWruNDD+8gFFa7LfbOkJmrZw tcqx90+xm2n9xKqwKMFsAp0= X-Google-Smtp-Source: ABdhPJxQseaY/NP1dDvJiBqak2dAqB39tVpR3Bmc6cYsQ9YKjzX/Zl4Qtx00HhMR98UlnIPDfnzDnA== X-Received: by 2002:a62:8243:0:b029:197:fe02:f950 with SMTP id w64-20020a6282430000b0290197fe02f950mr10816033pfd.80.1606564042948; Sat, 28 Nov 2020 03:47:22 -0800 (PST) Received: from localhost (61-68-227-232.tpgi.com.au. [61.68.227.232]) by smtp.gmail.com with ESMTPSA id k17sm14540704pji.50.2020.11.28.03.47.21 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Nov 2020 03:47:21 -0800 (PST) Date: Sat, 28 Nov 2020 22:47:18 +1100 From: Balbir Singh To: Andrew Morton Cc: Vlastimil Babka , linux-mm@kvack.org, mhocko@kernel.org, hannes@cmpxchg.org, vdavydov.dev@gmail.com Subject: Re: [PATCH] mm/list_lru: dont make them memcg aware if kmem is disabled Message-ID: <20201128114718.GC473773@balbir-desktop> References: <20201126043023.377343-1-bsingharora@gmail.com> <20201127092111.GA473773@balbir-desktop> <20201127194900.b66f2627a3d52529e401a6f1@linux-foundation.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201127194900.b66f2627a3d52529e401a6f1@linux-foundation.org> 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: On Fri, Nov 27, 2020 at 07:49:00PM -0800, Andrew Morton wrote: > On Fri, 27 Nov 2020 20:21:11 +1100 Balbir Singh wrote: > > > On Thu, Nov 26, 2020 at 01:10:18PM +0100, Vlastimil Babka wrote: > > > On 11/26/20 5:30 AM, Balbir Singh wrote: > > > > When alloc_super() allocates list_lrus for dentries and inodes > > > > they are made memcg aware if KMEM is compiled in, we should > > > > also check if kmem was disabled at runtime. > > > > > > > > This overhead is about 32 bytes extra per possible nodes per caller > > > > of list_lru_init() > > > > > > > > Signed-off-by: Balbir Singh > > > > > > I'd rather export cgroup_memory_nokmem and make cgroup_kmem_disabled() > > > inline, put it next to memcg_kmem_enabled() and explain in comments what > > > each means. > > > > > > And ideally, the current memcg_kmem_enabled() should be named e.g. > > > memcg_kmem_active(), and then the new cgroup_kmem_disabled() could be named > > > memcg_kmem_enabled(). But that's churn and potential future backport hazard, > > > so dunno. > > > > Yes, I am happy with whatever approach works to fast track the patches > > > > Andrew, thoughts/comments? > > > > Your original changelog doesn't make the case that the patch should be > fast tracked, so it looks like there's missing information. Please > don't miss information ;) > I just wanted to get the patches done :) Nothing to be seriously backported. I can refactor the code, I've seen cases where even with kmem disabled on pressure, kvmalloc leads to wasting memory for allocating memcg aware list_lrus. With older kernels (5.4 and before) where, creation of a new namespace always caused these allocations to occur via pid_ns_prepare_proc(), the issue is quite obviously exposed - the waster is a function of wasted_memory = sizeof (list_lru_memcg+4) * number of nodes * number of memcgs with kmem enabled ( per clone/container ) -- (1) That's not too bad today, but I am afraid it's useless memory being allocated and can become larger if the number of possible nodes increase. > If we're looking for a backportable quickfix for the > not-yet-really-explained problem then yes, Vlastimil's suggestion (as a > high-priority patch and a separate low-priority patch) sounds good. > > It is rather a twisty maze of identifiers, so please do comment > everything well. Yes, I am going to refactor things out a bit and resend the patches Balbir Singh.