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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id D5F16EB64DA for ; Thu, 20 Jul 2023 21:57:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3D69F280166; Thu, 20 Jul 2023 17:57:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3871B28004C; Thu, 20 Jul 2023 17:57:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 275FE280166; Thu, 20 Jul 2023 17:57:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 1604D28004C for ; Thu, 20 Jul 2023 17:57:55 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id D843F1C846E for ; Thu, 20 Jul 2023 21:57:54 +0000 (UTC) X-FDA: 81033353268.04.D3B8E1D Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf01.hostedemail.com (Postfix) with ESMTP id F35AD40009 for ; Thu, 20 Jul 2023 21:57:52 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=k7FUqjnE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1689890273; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=wl7nA+XKNyX4Yi/zc25RqNc24yJ/Bu5kqoLxAvSKOnM=; b=pUZFZf/GJTP3n//jioir9BvMahFmLItmEz3W93zsuLI6DuQS4yfsja3nytDKROd25tsd1S jefLj1gKY8P/pHLPb5swnLbWGg1njqTsRtO5dCtpkMq691q5fJtxk88n9niA3/j3x+Ox/6 dh/HU3ZhM6sIQ/lBdKsryu7GmyarrKg= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20221208 header.b=k7FUqjnE; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf01.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1689890273; a=rsa-sha256; cv=none; b=XwmVCf/cb1MwJyuqkjzpl+owjpxauagGt2uI3pAi4Lw0sBKWoeeJWbJttfugtfmz7y4SoO CSSCm9yHOdtrOefcC/8lzERPw7YSw6So64INm6odN976/7D4jj0FBhDWXnZbMtmtVVEXAE 0BFTdsKVY2Ge3yVxJ3QTh9zsfM4rLOA= Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-9923833737eso185277066b.3 for ; Thu, 20 Jul 2023 14:57:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1689890271; x=1690495071; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=wl7nA+XKNyX4Yi/zc25RqNc24yJ/Bu5kqoLxAvSKOnM=; b=k7FUqjnEFiSOQp+i6HnlTAtqd8i7KjoxW0qnaUvp3pqEOsDYpiKwv00fK7tWIAWq+V L0csr+6h25bw7M8HETXIGy57xadGMUTb+e6CM7je7HBnge+7UIs63cC/NX9JNu+6uJOs P6cH3lvuitbwqNzI3/AMCkdY9FWo4kAiwqQO9qA23dlpNqDR2mj75Ip0E/5g0EyHrFFD uudgugzFkworrkWgpHHed6DK9CZtPjS8L2YRWKq7tRAZdcMJyilsaCDXot4b7oXYYIa3 MzWUo1Y4OTmFKr/5RT/MwahFc9xlBuxiPJnnDMGRTs7uAflo4VtfGTAM+woDrrHj+p/0 BgEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1689890271; x=1690495071; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=wl7nA+XKNyX4Yi/zc25RqNc24yJ/Bu5kqoLxAvSKOnM=; b=b87+1JhV6aI5Rs9nUTtjviaYyzyLYOoCQhBe6eZ4iczr239ppVD/5yUBz6dSzLDMBx DYRdpAHtyIcBceU1UVxICrpluKlQUrOhCWnshoY+Pf7ocBi57aD50Z00yMNrYTRaDQUy oe+Zq847wJpvfLFgw3TDh0weLUdHglJ1jPC+pOAjDZp8hTPmBuWkYJYHUshP43c9az0k k3c9WLNyty2g/Dodv7iHTFWXiEUv9n6Q2oDZjk+6++eLcm95FZ7Plp/UfsufAisO8hlZ 1yyW1YeGw6rAXIoocXcP6NewqrsShVGsmlp7U6gwUWxXUxtdFwDp/Qz3xrYULt6VPHJD ZfwQ== X-Gm-Message-State: ABy/qLYOljdaTBiGb04SkxvvWM4OMjVOWpOIQWUkYMWi1CnI7QrWOMRC 9ciSko8thz8liQaubUQLndgLejiYQRpBqPqqeOPxTg== X-Google-Smtp-Source: APBJJlHXzUjLfQzs92T3qbk994d5sxZCnzhdaqzg6hOIFEuKrMB7os7XrcfkM2rrHCIE6VN/59C1ab1ttWzWOSvrh9s= X-Received: by 2002:a17:906:8a43:b0:99b:4bab:2839 with SMTP id gx3-20020a1709068a4300b0099b4bab2839mr43317ejc.55.1689890271331; Thu, 20 Jul 2023 14:57:51 -0700 (PDT) MIME-Version: 1.0 References: <20230713042037.980211-1-42.hyeyoo@gmail.com> <20230720071826.GE955071@google.com> In-Reply-To: From: Yosry Ahmed Date: Thu, 20 Jul 2023 14:57:15 -0700 Message-ID: Subject: Re: [RFC PATCH v2 00/21] mm/zsmalloc: Split zsdesc from struct page To: Hyeonggon Yoo <42.hyeyoo@gmail.com> Cc: Sergey Senozhatsky , Minchan Kim , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Matthew Wilcox , Mike Rapoport Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: F35AD40009 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: xakc1e4qkzxc8gtdsee5w73u1dk8hkfp X-HE-Tag: 1689890272-414126 X-HE-Meta: U2FsdGVkX19B9jBZhedvtjLD1vHXTCmXc/ZaI/yzhfyzRLMaYeBQ2Xp5tDjGZKBd+C36K1uSDB/VJljVayrRzeW8pR7tRKyuc72cY9opU7Uahi8cHsLmFEjBXI8E7Ot8D6bsoG0MPMSC0jZc919uT1gcYnXKI+OE5rLOSL3Fn4TGMVhA0mE5q+1gXtRmvjTUJWtdqprvQ+WlD5OE7e7hWSjLKh73M1nO2X3jPTU8sji1Or+fqSf/o/wDAmk171RnQeOrUvpNY3MlB6Ea32by0gpxRLKNav8tLaU9d+Lw1zS3t3eqlqQFh/I+qox8q6ykxtlkA/8OdGkETU/i6WpBl2Hr6Jv8GHIQKLqxDjNEukuG+MsVRiLsMITFN7j0udf2bS54JcX0duIBRGevnkpj4uOMYUvkKLr4xJ6C4C/W94jCB8QNAN95eX9ututADy2tbc9z3UlFyr/VM6LO0oaTnyEx4dK2nFz3T8h5nn2HTgGHBZ4LEJRJBiyCM4HLb9f05wkupamdgMKoI7EOa15D0C42yoxXRp8mQlza6qOhoLvN7BEHQS309B8SkxLEDLjirurrbNlSoP/TNAEGw/hcHbcHD3x6mhU9dhKUv7Uowyt7Gt7L5ebPZVZt0FdVtxzf34twJzQbUkjARa5+HSS3bjE47BhD4H1sHGKHxgWGZOSdDITCnLditIRqhjNrZEBfYohfb8u0S/f4Wi1N5c6qvb4DslQyldHZX1TRhUCcVm4ADCGu93LFM9ceOtfmIRaigaveYxhyff3zSivmjsqYT59go5lB6h+N17jNzxfpXQVJLfDQq9skti5dOeMbqGZWrzNJHr5Q5P9SKaRuaykxU1yxgnnTyJjtErKASCh2gDySmUOGXHdm4QMWIyrU3qbIGfUk9Ufc5KAferj/4LU3THk3ZS+64aZo84Ef6Lax3Q5U6HG8z1c/2r9VwWNkEGvpNsY2p3VNZmgVP0WMO2m 3SqjAKzg lGJbH/Acr5U+XLhiANRkZfKhVLXfDvq8ZwoJ0wusNlzCMqSFJJuCbvjUg7534aS5Y7O3Nai0ybURAs/V0TIuZboc9HAdZWwgeW9J+b2UHM86vS24UZHnuLVwa8gbG12CaQz7UFzUZWs7SZRO1afvPwS6vzs4+1sOMJZrOGjSOWz+J8REWxQrboar8n2YsuKeRJEoPE595HS0De/9knbWyfxpMcUqwOA2VWlH2R/HSEu4cLtAlH5OmrxhH3zNS6Nst9Z7Ue9O39BLx1+oNWdWPpjI4Qriggf9cV+pKryTHqdQ59F+68r4s/sZst1OOleqSjtu39/4FhgaDv2Wg3M+bhfzCDg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000096, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Jul 20, 2023 at 2:52=E2=80=AFPM Hyeonggon Yoo <42.hyeyoo@gmail.com>= wrote: > > On Fri, Jul 21, 2023 at 6:39=E2=80=AFAM Yosry Ahmed wrote: > > > > > > > > > > > > > It seems to me though the sizeof(zsdesc) is actually 56 bytes (= on > > > > > > 64-bit), so sizeof(zsdesc) + sizeof(memdesc) would be equal to = the > > > > > > current size of struct page. If that's true, then there is no l= oss, > > > > > > > > > > Yeah, zsdesc would be 56 bytes on 64 bit CPUs as memcg_data field= is > > > > > not used in zsmalloc. > > > > > More fields in the current struct page might not be needed in the > > > > > future, although it's hard to say at the moment. > > > > > but it's not a loss. > > > > > > > > Is page->memcg_data something that we can drop? Aren't there code > > > > paths that will check page->memcg_data even for kernel pages (e.g. > > > > __folio_put() -> __folio_put_small() -> mem_cgroup_uncharge() ) ? > > > > > > zsmalloc pages are not accounted for via __GFP_ACCOUNT, > > > > Yeah, but the code in the free path above will check page->memcg_data > > nonetheless to check if it is charged. > > Right. > > > I think to drop memcg_data we need to enlighten the code that some page= s > > do not even have memcg_data at all > > I agree with you. It should be one of the milestones for all of this to w= ork. > It won't be complicated for the code to be aware of it, because there wil= l be > a freeing (and uncharging if need) routine per type of descriptors. Right. For this patch series, do we need to maintain memcg_data in zsdec to avoid any subtle problems?