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=-5.7 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED 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 B92D3C4361B for ; Mon, 7 Dec 2020 15:09:06 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 4D9B52370D for ; Mon, 7 Dec 2020 15:09:06 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4D9B52370D Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8B8198D0002; Mon, 7 Dec 2020 10:09:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8690E8D0001; Mon, 7 Dec 2020 10:09:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 77E958D0002; Mon, 7 Dec 2020 10:09:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0054.hostedemail.com [216.40.44.54]) by kanga.kvack.org (Postfix) with ESMTP id 5D1428D0001 for ; Mon, 7 Dec 2020 10:09:05 -0500 (EST) Received: from smtpin22.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id EBFD034A3 for ; Mon, 7 Dec 2020 15:09:04 +0000 (UTC) X-FDA: 77566819008.22.end85_20139d1273df Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin22.hostedemail.com (Postfix) with ESMTP id BD93218038E67 for ; Mon, 7 Dec 2020 15:09:04 +0000 (UTC) X-HE-Tag: end85_20139d1273df X-Filterd-Recvd-Size: 3664 Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by imf39.hostedemail.com (Postfix) with ESMTP for ; Mon, 7 Dec 2020 15:09:04 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1607353743; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=7RsLkVdlKW2JLj2RfGQG78NhVgvfEuANtMbySI98QQQ=; b=FpL5im6xdBPNTwI0VJejyVkNHligc44w05ikwoMOxpq6LgNg3/4lSSlUjejunNBLXOIRIn F0HGr8LRMJYqby5qTOJhh9/p3FqCfVQA74WaKBYtiB99a/gVZp53Wd7MMzQkD7NLJ38uNB b1W+ClaJOZdhrEoN/UrEnHLAZTf4Kcw= Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CEB01ABE9; Mon, 7 Dec 2020 15:09:02 +0000 (UTC) Date: Mon, 7 Dec 2020 16:09:01 +0100 From: Michal Hocko To: Muchun Song Cc: Johannes Weiner , Vladimir Davydov , Andrew Morton , Shakeel Butt , Roman Gushchin , Stephen Rothwell , alexander.h.duyck@linux.intel.com, Chris Down , Yafang Shao , richard.weiyang@gmail.com, LKML , Cgroups , Linux Memory Management List Subject: Re: [External] Re: [PATCH] mm: memcontrol: optimize per-lruvec stats counter memory usage Message-ID: <20201207150847.GM25569@dhcp22.suse.cz> References: <20201206085639.12627-1-songmuchun@bytedance.com> <20201207123605.GH25569@dhcp22.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Mon 07-12-20 20:56:58, Muchun Song wrote: > On Mon, Dec 7, 2020 at 8:36 PM Michal Hocko wrote: > > > > On Sun 06-12-20 16:56:39, Muchun Song wrote: > > > The vmstat threshold is 32 (MEMCG_CHARGE_BATCH), so the type of s32 > > > of lruvec_stat_cpu is enough. And introduce struct per_cpu_lruvec_stat > > > to optimize memory usage. > > > > How much savings are we talking about here? I am not deeply familiar > > with the pcp allocator but can it compact smaller data types much > > better? > > It is a percpu struct. The size of struct lruvec_stat is 304(tested on the > linux-5.5). So we can save 304 / 2 * nproc bytes per memcg where nproc > is the number of the possible CPU. If we have n memory cgroup in the > system. Finally, we can save (152 * nproc * n) bytes. In some configurations, > nproc here may be 512. And if we have a lot of dying cgroup. The n can be > 100, 000 (I once saw it on my server). This should be part of the changelog. In general, any optimization should come with some numbers showing the effect of the optimization. As I've said I am not really familiar with pcp internals and how efficiently it can organize smaller objects. Maybe it can really half the memory consumption. My only concern is that using smaller types for these counters can fire back later on because we have an inderect dependency between the batch size and the data type. In general I do not really object to the patch as long as savings are non trivial so that we are not creating a potential trap for something that is practically miniscule microptimization. -- Michal Hocko SUSE Labs