Received: by 2002:a05:6358:5282:b0:b5:90e7:25cb with SMTP id g2csp2545615rwa; Mon, 22 Aug 2022 09:20:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR5t/nBs2ca5psudsOUZpeG/Oghkfkfn/rIFvpSmosKw7pIjVdV+O7SKZT+xy/vLNKkZmBJ2 X-Received: by 2002:aa7:93a4:0:b0:535:d714:c24c with SMTP id x4-20020aa793a4000000b00535d714c24cmr20278535pff.15.1661185199756; Mon, 22 Aug 2022 09:19:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1661185199; cv=none; d=google.com; s=arc-20160816; b=yIUuBXLGgerCM3ebw8IXFpDwH0RQeW3ZwtjE6kJpturqIRCxVotoIYGZuKCG+9nu9s 1S5+CUbHDHm3UiibmgWvP6uZHCi3tWM5DbdTLeWt7oBZDoQc623qy1+8jN37pYPKTKmX H3Jcsx2EtwyY+glGcbnkK/UmycO4GEmgAPKWbTDfJLadOuDhccIbEz6wdBaUoqXiRpau 7nYIbls480rxwMlpUfBa/rWJI5RJ5yZlaDNFacJssYBSiw4UxHBcveX7v+vAygs3FiX6 paFuLwfu9MJoOJZZg9eLakj3xGau6/LRv7hsgUDUZSRT9zfDBoG4Tv0/pB8R4sooA3W9 TB9A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=Gsdq66BkjynIpRPrwWnOavgdKVDsGQ5+owwtyl9S4wc=; b=aNGRY8Nz09b4ePVL2RJz0wp2WezVbGXWKRvdsLkzts58k8Knd8q4qJhAqCeLi+fqcL zPpJn2qk5HXuSaiHq1D8UTLorp0xWE+tyURKxDRrWUhZGf5vS9BodMz3B2z6oB2t6+xH iSSqP4CoYjumdotrjb/lyLeo8dGX4gPVVnXEP3l3eHnCBBw0si38AUhK8guwkYgBlI7W 332Dri7jpBuDd1BFO1sfoPJTAU3S6sYZ6/9IdCHHICAjKbh2Q3OWng4Ad33RELuLaOzu frUAKR+OLy081tApYhiYXN9YY5hYg0If3d6TLmGOARdhxLDMNs42OUNpoQTEn5UggPc9 vu0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FCtgY9ii; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id bi2-20020a170902bf0200b00172696f35e1si12438845plb.482.2022.08.22.09.19.48; Mon, 22 Aug 2022 09:19:59 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=FCtgY9ii; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234788AbiHVQFV (ORCPT + 99 others); Mon, 22 Aug 2022 12:05:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49018 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233909AbiHVQFM (ORCPT ); Mon, 22 Aug 2022 12:05:12 -0400 Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FB2D1BE83 for ; Mon, 22 Aug 2022 09:05:11 -0700 (PDT) Received: by mail-pg1-x52f.google.com with SMTP id 12so9787107pga.1 for ; Mon, 22 Aug 2022 09:05:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=Gsdq66BkjynIpRPrwWnOavgdKVDsGQ5+owwtyl9S4wc=; b=FCtgY9iinm8oIY5V3F0fuHisMULPTP8CQ+xh/Bo5Gk3eVocKSH5pJdqM+NrFCk5yNp C/YGEDtKfv2IeT6AmCu73ng/KgcB1e3J6zvGZBDJaQRXHcj3tN23Tv/MhEOscujEMLJ5 xyYk5bpEg2crzlxiekFp9X9OD/yfiaG6k0mDe8aulUmg8Umb7MrkjHZX4pGlK3JTLFNe Ywl56Z7zDPixLCxQT7eP7burucLhwhQBi8Bmc51HtR0S3LB5qkV698CWc9NctsG4DkCE 5U6M+vkFI6nGdhVyAgLZmrPCSAgv732qwe2Dng3VOnpr0ocEVXV6qBHvaBbf6pfIfatM h98g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=Gsdq66BkjynIpRPrwWnOavgdKVDsGQ5+owwtyl9S4wc=; b=WNgQo6Q3M3lxEhyEtQcw0Mm+FUrGGqZxIHx8o1VG3zn7xDUHpvezgD4X5m0tIEzJJd ZTzpm+3YJiLuOXn4F9MzpfgNpu+q40TyFg/PiCNjQvS39ZgUnQi7osxUsqMoNAahh20u qoHc8WZc7ive6g9C2ykNTZf3Sa9L/SecoOsvcb65CPMp04YBvsD5OSf9TKjnuB90km0t V8zwmoZWs7XkEzgURNmQvr7Tkcstr1+vLuNN+LaekZ6iFPr9CmuLLuSe5+3opg0+54H6 aBr+ciM2PzXyzcv36xRnodt0n2irVjwjhjzuQvXuyNlYQ/qbtqt1KLRSQc0K9O9PLg6r MMCA== X-Gm-Message-State: ACgBeo0Lt0EcS4B01iUp4SFxbkmJHrgT0TDoup0fs2Mrk5bfudyz5+VK HKeMb6Z5zv5tFrrF5Ap5G16KW2W4wMoZrm7rYvzSHA== X-Received: by 2002:a63:5f8e:0:b0:429:c286:4ef7 with SMTP id t136-20020a635f8e000000b00429c2864ef7mr17156340pgb.166.1661184310649; Mon, 22 Aug 2022 09:05:10 -0700 (PDT) MIME-Version: 1.0 References: <20220822001737.4120417-1-shakeelb@google.com> <20220822001737.4120417-3-shakeelb@google.com> In-Reply-To: From: Shakeel Butt Date: Mon, 22 Aug 2022 09:04:59 -0700 Message-ID: Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields To: Michal Hocko Cc: Johannes Weiner , Roman Gushchin , Muchun Song , =?UTF-8?Q?Michal_Koutn=C3=BD?= , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, Cgroups , Linux MM , netdev , LKML Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE,USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 22, 2022 at 8:15 AM Michal Hocko wrote: > > On Mon 22-08-22 08:06:14, Shakeel Butt wrote: > [...] > > > > struct page_counter { > > > > + /* > > > > + * Make sure 'usage' does not share cacheline with any other field. The > > > > + * memcg->memory.usage is a hot member of struct mem_cgroup. > > > > + */ > > > > + PC_PADDING(_pad1_); > > > > > > Why don't you simply require alignment for the structure? > > > > I don't just want the alignment of the structure. I want different > > fields of this structure to not share the cache line. More > > specifically the 'high' and 'usage' fields. With this change the usage > > will be its own cache line, the read-most fields will be on separate > > cache line and the fields which sometimes get updated on charge path > > based on some condition will be a different cache line from the > > previous two. > > I do not follow. If you make an explicit requirement for the structure > alignement then the first field in the structure will be guarantied to > have that alignement and you achieve the rest to be in the other cache > line by adding padding behind that. Oh, you were talking explicitly about _pad1_, yes, we can remove it and make the struct cache align. I will do it in the next version.