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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_PASS, URIBL_BLOCKED,USER_AGENT_MUTT autolearn=ham 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 717B0C10F11 for ; Wed, 24 Apr 2019 18:53:09 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 3A0EE2183E for ; Wed, 24 Apr 2019 18:53:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556131989; bh=YvWLgidcsNnrPA8XicgNYDeG5R59r5QJsFX1VtKi+qU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:List-ID:From; b=IkJtjfS6eQB3lqDrBwPqxX6l8RspH+lfjtbNuPbgiqvezE7vjZkgXWyluizF6DNiY UjLXPFKfXPc/ZPaq8d0LOOv9Gf+5JeZrw2pTiK2mF64dyK87Vx1nfQW/1kQmUA14s7 ia7k2gWExlMOwKPV+f7fiarZe1iNYVvfiTOmsz5I= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726869AbfDXSxI (ORCPT ); Wed, 24 Apr 2019 14:53:08 -0400 Received: from mail.kernel.org ([198.145.29.99]:45404 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726419AbfDXSxI (ORCPT ); Wed, 24 Apr 2019 14:53:08 -0400 Received: from localhost (62-193-50-229.as16211.net [62.193.50.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 85A27208E4; Wed, 24 Apr 2019 18:53:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1556131988; bh=YvWLgidcsNnrPA8XicgNYDeG5R59r5QJsFX1VtKi+qU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BC4MYGbstugvAR/PNy/9pG2T8L+uUoUJC5ZSaQQDyPthjcP10BWYmHGjpA3hVb/NZ zeVd5nDg6NWMmGve+NjpxVvnRNSbvTc2OKIMW6zAMIy6Fl/Q8/NRZsc4aSrsLG3DMW xgulqZRNqsFBSX3SyA7UTzFxwAbMWeV1Hv8xYp9Y= Date: Wed, 24 Apr 2019 20:34:19 +0200 From: Greg KH To: Vaibhav Rustagi Cc: stable@vger.kernel.org, hannes@cmpxchg.org, tj@kernel.org, mhocko@suse.com, vdavydov.dev@gmail.com, guro@fb.com, riel@surriel.com, sfr@canb.auug.org.au, akpm@linux-foundation.org, torvalds@linux-foundation.org, Aditya Kali Subject: Re: [For Stable] mm: memcontrol: fix excessive complexity in memory.stat reporting Message-ID: <20190424183419.GB10495@kroah.com> References: <20190424165009.GE21916@kroah.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.11.4 (2019-03-13) Sender: stable-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: stable@vger.kernel.org A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? A: No. Q: Should I include quotations after my reply? http://daringfireball.net/2007/07/on_top On Wed, Apr 24, 2019 at 10:35:51AM -0700, Vaibhav Rustagi wrote: > Apologies for sending a non-plain text e-mail previously. > > This issue is encountered in the actual production environment by our > customers where they are constantly creating containers > and tearing them down (using kubernetes for the workload). Kubernetes > constantly reads the memory.stat file for accounting memory > information and over time (around a week) the memcg's got accumulated > and the response time for reading memory.stat increases and > customer applications get affected. Please define "affected". Their apps still run properly, so all should be fine, it would be kubernetes that sees the slowdowns, not the application. How exactly does this show up to an end-user? > The repro steps mentioned previously was just used for testing the > patches locally. > > Yes, we are moving to 4.19 but are also supporting 4.14 till Jan 2020 > (so production environment will still contain 4.14 kernel) If you are already moving to 4.19, this seems like a good as reason as any (hint, I can give you more) to move off of 4.14 at this point in time. There's no real need to keep 4.14 around, given that you don't have any out-of-tree code in your kernels, so all should be simple to just update the next reboot, right? thanks, greg k-h