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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5D742C32772 for ; Mon, 22 Aug 2022 15:23:28 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236582AbiHVPXY (ORCPT ); Mon, 22 Aug 2022 11:23:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236482AbiHVPV7 (ORCPT ); Mon, 22 Aug 2022 11:21:59 -0400 Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2001:67c:2178:6::1d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B86863E767; Mon, 22 Aug 2022 08:15:10 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 9F132202FF; Mon, 22 Aug 2022 15:15:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661181308; 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=Ko/ZbbYlRZVDcCBDACh47r5MpCi7V/QJtzGfx/uTT4o=; b=AXWrARvl88HySuV2IvKZojEAAxu+6WFr21jizwVhd03l87uhLlzEhtWF1q5t+tYCKFoU1r zhU9Xf5P/O2u82zIGY3fhc2PPA5D+bx5XJNxv1WYALMnAhhLQVdq10YN3QdYT/wpkS5CBR HnhzLzMG9IccwSBFROGrZYIj9DWOx1g= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 6F85F1332D; Mon, 22 Aug 2022 15:15:08 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id U/SfGHydA2PFEwAAMHmgww (envelope-from ); Mon, 22 Aug 2022 15:15:08 +0000 Date: Mon, 22 Aug 2022 17:15:07 +0200 From: Michal Hocko To: Shakeel Butt Cc: Johannes Weiner , Roman Gushchin , Muchun Song , Michal =?iso-8859-1?Q?Koutn=FD?= , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp@lists.01.org, Cgroups , Linux MM , netdev , LKML Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields Message-ID: References: <20220822001737.4120417-1-shakeelb@google.com> <20220822001737.4120417-3-shakeelb@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. -- Michal Hocko SUSE Labs From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: multipart/mixed; boundary="===============8164338445979632922==" MIME-Version: 1.0 From: Michal Hocko To: lkp@lists.01.org Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields Date: Mon, 22 Aug 2022 17:15:07 +0200 Message-ID: In-Reply-To: List-Id: --===============8164338445979632922== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On Mon 22-08-22 08:06:14, Shakeel Butt wrote: [...] > > > struct page_counter { > > > + /* > > > + * Make sure 'usage' does not share cacheline with any other fi= eld. 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. -- = Michal Hocko SUSE Labs --===============8164338445979632922==-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: [PATCH 2/3] mm: page_counter: rearrange struct page_counter fields Date: Mon, 22 Aug 2022 17:15:07 +0200 Message-ID: References: <20220822001737.4120417-1-shakeelb@google.com> <20220822001737.4120417-3-shakeelb@google.com> Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1661181308; 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=Ko/ZbbYlRZVDcCBDACh47r5MpCi7V/QJtzGfx/uTT4o=; b=AXWrARvl88HySuV2IvKZojEAAxu+6WFr21jizwVhd03l87uhLlzEhtWF1q5t+tYCKFoU1r zhU9Xf5P/O2u82zIGY3fhc2PPA5D+bx5XJNxv1WYALMnAhhLQVdq10YN3QdYT/wpkS5CBR HnhzLzMG9IccwSBFROGrZYIj9DWOx1g= Content-Disposition: inline In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Shakeel Butt Cc: Johannes Weiner , Roman Gushchin , Muchun Song , Michal =?iso-8859-1?Q?Koutn=FD?= , Eric Dumazet , Soheil Hassas Yeganeh , Feng Tang , Oliver Sang , Andrew Morton , lkp-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org, Cgroups , Linux MM , netdev , LKML 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. -- Michal Hocko SUSE Labs