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=-0.7 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 F3421C2D0DD for ; Thu, 2 Jan 2020 05:43:43 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 907B1206E6 for ; Thu, 2 Jan 2020 05:43:43 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="vBaW66ej" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 907B1206E6 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 EA59D8E0005; Thu, 2 Jan 2020 00:43:42 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id E55528E0003; Thu, 2 Jan 2020 00:43:42 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D6B8E8E0005; Thu, 2 Jan 2020 00:43:42 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0226.hostedemail.com [216.40.44.226]) by kanga.kvack.org (Postfix) with ESMTP id C20318E0003 for ; Thu, 2 Jan 2020 00:43:42 -0500 (EST) Received: from smtpin24.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id 70B6A181AC9B6 for ; Thu, 2 Jan 2020 05:43:42 +0000 (UTC) X-FDA: 76331602284.24.smoke15_7799038a6bd43 X-HE-Tag: smoke15_7799038a6bd43 X-Filterd-Recvd-Size: 5417 Received: from mail-il1-f193.google.com (mail-il1-f193.google.com [209.85.166.193]) by imf32.hostedemail.com (Postfix) with ESMTP for ; Thu, 2 Jan 2020 05:43:41 +0000 (UTC) Received: by mail-il1-f193.google.com with SMTP id c4so33327346ilo.7 for ; Wed, 01 Jan 2020 21:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CoTcN/UoEpgu0ki8Gbz6omide0ghgkw3Qg3WB5ASFuM=; b=vBaW66ejLk24rA/QXFYmOnb6f3S3I16uIx0e+PN0w5+LcgjzQMr2GfV/bbxGpV4WP5 hhEwI0wuy952F9EHTnwyMNMhv6RxuAj3LJJFlGh0H9U8e4rz9aVvPE/HNtCGronK+g7O knhuMHNlGDqFK67psovGHWYstuvNv3HpJCoIcdxIxxuzoONc0wAzxdMj6VArnUQpki0e +IBIjN7bI8kkXkAeQQAkcOp0fZp3//UoPPdSp+pEkFdmzEohYpOnaL+wZE/nobhwL9zB gXbaPlZIC/5pzUI7avgizy3UywFvw6EiJJe6dg3kdh2AP5MYja8dIKhnCfIfv91qzXl1 JiSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CoTcN/UoEpgu0ki8Gbz6omide0ghgkw3Qg3WB5ASFuM=; b=lsLW0QUkJakDVRkU9bcRUkYTypyVtQb/T7s/w8KI9qRHi3M8D6nYfLb/pmJJHm/LLk 7LDmGylDsF1RedMrr/WBO6LNOcHQ/jHxAhKwlh64aosHpd9JdLeih6rfmmGKKbpV2giQ kRtt1zQV52ax+JwaKunsotN+8+YFnx4rwf30Ui5WPq1SsAfomCZT8ZHclBSKje+2dDTZ 62Gj202J93snjgpqsrxV2bL9FdPQZsE3Zhjv7/RLeEY/B0fvnKiJgZg03tX2wEIn+rVy w+5MZT13JcELBxcwIYelQSeY+xbCd63XqD+ddCY85cU3NuP1OPH/+nHihGCq5xqncyj9 LWlw== X-Gm-Message-State: APjAAAWpntKqfbgo1opIFoscJXPwT0xGLagKMYaIp9pTsDLXW4L7bSiJ hXCsoPNUXx3kLVbr+yP0VlSkdosZ7nLf1mqIRNE= X-Google-Smtp-Source: APXvYqwE6KziY6IILwhsiEH5MrcASdwJBU8qAK/cs+BSWTH6hoUeCm8+Cbzbjiybla7HvSepzC8Po19ZbNhEEYfohxE= X-Received: by 2002:a92:84ce:: with SMTP id y75mr67473959ilk.93.1577943821157; Wed, 01 Jan 2020 21:43:41 -0800 (PST) MIME-Version: 1.0 References: <1577450633-2098-1-git-send-email-laoar.shao@gmail.com> <20191231143139.20a912b3386548062343a5b2@linux-foundation.org> In-Reply-To: <20191231143139.20a912b3386548062343a5b2@linux-foundation.org> From: Yafang Shao Date: Thu, 2 Jan 2020 13:43:05 +0800 Message-ID: Subject: Re: [PATCH] mm, memcg: reduce size of struct mem_cgroup by using bit field To: Andrew Morton Cc: Roman Gushchin , Johannes Weiner , Michal Hocko , Vladimir Davydov , Linux MM Content-Type: text/plain; charset="UTF-8" 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 Wed, Jan 1, 2020 at 6:31 AM Andrew Morton wrote: > > On Fri, 27 Dec 2019 07:43:52 -0500 Yafang Shao wrote: > > > There are some members in struct mem_group can be either 0(false) or > > 1(true), so we can define them using bit field to reduce size. With this > > patch, the size of struct mem_cgroup can be reduced by 64 bytes in theory, > > but as there're some MEMCG_PADDING()s, the real number may be different, > > which is relate with the cacheline size. Anyway, this patch could reduce > > the size of struct mem_cgroup more or less. > > > > ... > > > > --- a/include/linux/memcontrol.h > > +++ b/include/linux/memcontrol.h > > @@ -229,20 +229,26 @@ struct mem_cgroup { > > /* > > * Should the accounting and control be hierarchical, per subtree? > > */ > > - bool use_hierarchy; > > + unsigned int use_hierarchy : 1; > > + > > + /* Legacy tcp memory accounting */ > > + unsigned int tcpmem_active : 1; > > + unsigned int tcpmem_pressure : 1; > > Kernel coding style for this is normally no-spaces: > > bool foo:1; > I always learn the kernel coding style from the kernel source code. Before I tried to define them using bit field in the kernel, I checked what the kernel did in the past. I found there're some places defined with spaces[1], some places defined without spaces[2]. Finally I selected the one with spaces, unfortunately that's the wrong one . Anyway I know what the right thing is now, thanks. [1]. https://elixir.bootlin.com/linux/v5.5-rc4/source/include/linux/tcp.h#L87 [2]. https://elixir.bootlin.com/linux/v5.5-rc4/source/include/linux/tcp.h#L213 > > > More significantly... Now that these fields share the same word of > memory, what prevents races when two CPUs do read-modify-write > operations on adjacent bitfields? > > This: > > struct foo { > int a; > int b; > }; > > doesn't need locking to prevent modifications of `a' from scribbling on > `b'. But with this: > > struct foo { > int a:1; > int b:1; > } > > a simple `a = 1' on CPU1 could race with a `b = 1' on CPU2. > > I think. Maybe the compiler can take care of this in some fashion, but > it would require atomic bitops and I doubt if gcc does that for us? > > GCC can guarantees that accesses to distinct structure members (which aren't part of a bit-field) are independent, but it can't guarantee that to bitfields. I thought there are some synchronization mechanism to protect memcg against concurrent access. Thanks Yafang