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 102A1C48BC3 for ; Sun, 18 Feb 2024 00:44:21 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7676D6B008C; Sat, 17 Feb 2024 19:44:21 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 6EFBA6B0092; Sat, 17 Feb 2024 19:44:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5699F6B0093; Sat, 17 Feb 2024 19:44:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 3EEFB6B008C for ; Sat, 17 Feb 2024 19:44:21 -0500 (EST) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D981D80138 for ; Sun, 18 Feb 2024 00:44:20 +0000 (UTC) X-FDA: 81803078280.08.A2C3083 Received: from mail-yw1-f179.google.com (mail-yw1-f179.google.com [209.85.128.179]) by imf14.hostedemail.com (Postfix) with ESMTP id 1DAF410000A for ; Sun, 18 Feb 2024 00:44:18 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jxd0yfzO; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708217059; 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=cFEGcM8EospHG4JmqyUXYLdSoH1Alzf1U0lPv6eqJTM=; b=8MnpC7hEkyH8qGS48o3lxfoddtxAF0h0dcL+f0LepX1d44z3TNBlGEfl/Z6iPZMwsTpQ3W DSxTLqDAK/2Xe30k/ZgRobIN45tRvcsB4+VtLo44keqA7WlwxjpYhuCi6mWIP+JI6MTtzg nyKHHqBt4RYHtIM9HDIzYOho2nrUYfI= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Jxd0yfzO; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.128.179 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708217059; a=rsa-sha256; cv=none; b=RclHTS7VB0QQPc/VGuQAi3lj5E/H9sy/BPIV3K1s2IDIgqxn26inUHAWWKhZ9wLe1VuJ/W pbFK9RWZJD4mLkd3J+e4w6uLaSFISmUjG1kFvUVITBrizCvzq8zcGEhym3tiPG59TmJIbd Esi3O47cRd8K4QXykLsVvDixi37Zfw4= Received: by mail-yw1-f179.google.com with SMTP id 00721157ae682-6080a3eecd4so10966057b3.2 for ; Sat, 17 Feb 2024 16:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1708217058; x=1708821858; darn=kvack.org; 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=cFEGcM8EospHG4JmqyUXYLdSoH1Alzf1U0lPv6eqJTM=; b=Jxd0yfzOe+yZ0Ou2trGUaZTS+ifBcA+J8Iptvs/hHXbprR22sihlqpcOgUXTdl9KsO sakEEpRIFFSL8UQNuLCiU9Tdd3wccQd1scbJGQjn7h95LCAjG76OLs4MPvvIQkrRJndj PjnmCl2tBDZWjI9fYvmis5Wo3oxaK7EibMKiOw/uSDpLyvipYcFWCru1W/nmKMiD5lCK pqhgMBGnvmk6m8FM6wk/D4y5v/f6pWWADBXjQO4fQVsU19fV8C51a3oBS4nz5rhOXa8F nO/AbBy70lPMnfAUrUwX3LZrWQa85z9uVuwEgPyzbpInt97mtNEJ02g9WXStR3/GhnO9 GeJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1708217058; x=1708821858; 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=cFEGcM8EospHG4JmqyUXYLdSoH1Alzf1U0lPv6eqJTM=; b=az0uckuEVwfCdD9Go3hRb6m3XCFP7R/bqX49IV/Q3qw6ImoUdTed/Z+riWpQqRAAOy kgfsJxyruAlVWc6q9lUoG+O1JexcLCuzmmeCb794orQFC6kOlfBIjPBM+wnC1e0/30Jm i6Dr8vVTIdUFJaAAMcAqG+W7RgdSMDssaHpE8FrwGQYL9XsgCAxxlN7ulTtxOVnlX58t 5bUtoRVU+Kct4vfJSTb/jG+CyLgJZFtOhS51uJWqR/tLI1jaR77BJW4yOKMK5PsjlCnD OLFZXP7VdYhZh69o9lRzSH51CFnR3F8p5tkQDU/3zwn5q2OPPFk18oRKitrNUvzh7kdg 4pKQ== X-Forwarded-Encrypted: i=1; AJvYcCVsoqlnSvgUayKWkwCH2qFT4gR/MIE0AUTCLbNuCZwVauviCFwN8Y1SgqfsEGJ2xaGtfZ1ClHMJziXbmpzid4BZ1S4= X-Gm-Message-State: AOJu0YwzFn/QR70LoexxZyI2RmNNdbX2hNllyf66vFNJh4XuBMeSckv2 BrLv9stcNcqkO5Pqh7UGctcqimX4T2d65mOGxnS1DERSXbBo8M+1WyCzovTh6zNWyoDryvFmVve uiLaUEhz2Clo9uiHr+pbFIK+4Wo3F9mdeSbkc X-Google-Smtp-Source: AGHT+IF0zbur3ZnS0QBbUiRVZnclSCZcw12C5kwuIUJh6ZOEbr9od3x9F9LKEta3pcFjU0rivXF1DW3eH5+/zL6adzk= X-Received: by 2002:a81:914a:0:b0:604:f681:a1 with SMTP id i71-20020a81914a000000b00604f68100a1mr9152837ywg.16.1708217057719; Sat, 17 Feb 2024 16:44:17 -0800 (PST) MIME-Version: 1.0 References: <20240212213922.783301-1-surenb@google.com> <20240212213922.783301-19-surenb@google.com> <2e26bdf7-a793-4386-bcc1-5b1c7a0405b3@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Sun, 18 Feb 2024 00:44:05 +0000 Message-ID: Subject: Re: [PATCH v3 18/35] mm: create new codetag references during page splitting To: Vlastimil Babka Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, mhocko@suse.com, hannes@cmpxchg.org, roman.gushchin@linux.dev, mgorman@suse.de, dave@stgolabs.net, willy@infradead.org, liam.howlett@oracle.com, corbet@lwn.net, void@manifault.com, peterz@infradead.org, juri.lelli@redhat.com, catalin.marinas@arm.com, will@kernel.org, arnd@arndb.de, tglx@linutronix.de, mingo@redhat.com, dave.hansen@linux.intel.com, x86@kernel.org, peterx@redhat.com, david@redhat.com, axboe@kernel.dk, mcgrof@kernel.org, masahiroy@kernel.org, nathan@kernel.org, dennis@kernel.org, tj@kernel.org, muchun.song@linux.dev, rppt@kernel.org, paulmck@kernel.org, pasha.tatashin@soleen.com, yosryahmed@google.com, yuzhao@google.com, dhowells@redhat.com, hughd@google.com, andreyknvl@gmail.com, keescook@chromium.org, ndesaulniers@google.com, vvvvvv@google.com, gregkh@linuxfoundation.org, ebiggers@google.com, ytcoode@gmail.com, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, bristot@redhat.com, vschneid@redhat.com, cl@linux.com, penberg@kernel.org, iamjoonsoo.kim@lge.com, 42.hyeyoo@gmail.com, glider@google.com, elver@google.com, dvyukov@google.com, shakeelb@google.com, songmuchun@bytedance.com, jbaron@akamai.com, rientjes@google.com, minchan@google.com, kaleshsingh@google.com, kernel-team@android.com, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, iommu@lists.linux.dev, linux-arch@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-modules@vger.kernel.org, kasan-dev@googlegroups.com, cgroups@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 1DAF410000A X-Rspam-User: X-Stat-Signature: kg53qgz5k4ukujeryizuj6sn6k8a1quq X-Rspamd-Server: rspam01 X-HE-Tag: 1708217058-76664 X-HE-Meta: U2FsdGVkX1/Pj+hKhYw+DI33KlqH6G4/AgN9GmUrRPBOU2QXmGsKEfZ/DsOgd8u+P7G2SCigDYeHLiQQq13MQn9lnlH1kgpnB3CZ+XgZFqXj+l2zEFtygiE5BFRGGNEVky6G4hymXMg6OLy0tVv4i9Z05lsOlTxBMmPrxOx0GXSvBVDS+H9BvEs4OYXNQ2rNOAZV3wQL6TnumdP2qwNUzh2Ff2rovGX6YzX7TcWnYuztG2668IF8hJAjHMZQCq78moCJjR4GbvLSpkjUIg0uYcvfdk4TOdJqtkKjnxDMj3eViCbW92dzikeVOsnTquWGdJXhYy+7kJCaUVoGNTGEZcRyGUy5Z51tDvvq8LMgEPzAsqASPWZGeyMxFUusFqrGNrMw6ZzDEclBhLUje66P4a0m2sYc50E8hyn7xkVi5DgkHbabWTK2125khDsGXyVflUP8E2T/jT8UdpG3eEb7VYT9oU+IZ7iekfeyBoMd6AihsdU9SEC1KR6mMRa9pm70hOFbw2y4aWU+lZG6LSyYOUt1UgNg78r604/9O3O5LD8D+KzXHe5lhGSVQZcnyTE5hS1YyN5MouwQUJVJnA4oC1FP3UsMbbLWa2q7+V4ONlG7yO4uR/prt4I54iNicLk9qO1q9cHJG8HJ2tJknM5GMTqDKrP/HPlLg+nq0tP34/Tr50GV3orPculdtH1Yek19kE7QhORPBuNDDsmTsVjDoIlcXi1ZTgMwQJK0FBtolLODhtmhJaIhgNP4bWMcyjqqmO9zUI0G8cATui7kFt36pTtGWpbXVI/rr+Dyjujr0sYroEq6tvr7llqh2G6ku6GYE9BK/rxPz3CpnbAKcv6gpdoFbMa/3IehNzs2pH4WhCKYAPFwiwMQzMCHfVW7GjVuXfjgcN3SV9Rky4h5lKjHOi+FrXhLLlb8RPphp1mW+GwLF0EDEDRRS6JuPzmB7hxjHQOBHpgQHkoJkSBc4y8 2DcbI8I0 SpIg+g2njOnIhGCjS+lRazeyNUAN9iZrw3AmvGZ5eIP8ANdXa6y4SA+ozsh3xe7CxB+hNsiL7JIYOCKBlV8FfjcYeGYEyLE9XpjIX++tHWxUVLzWp5T3VdAyqBM8KonQRVw8FgKEgV9w+ZAM0l0HOZCRYIh70RlnU5I15kX4xoFrZgOEdJs0OYyKi1OYZo24Ij7GIXEAQ8TVSNhKV4r6b8BI+3KGsWfnCXFzgKXLmW9zMOU7eTncGJ4drnng72KZqDY6m7BbDtvZX/2e8+E+BTd+D2YR1tIKMGVr5btVDQKJs43hRpbUDoKYfhBGunhXP7giQ 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: List-Subscribe: List-Unsubscribe: On Fri, Feb 16, 2024 at 4:46=E2=80=AFPM Suren Baghdasaryan wrote: > > On Fri, Feb 16, 2024 at 6:33=E2=80=AFAM Vlastimil Babka = wrote: > > > > On 2/12/24 22:39, Suren Baghdasaryan wrote: > > > When a high-order page is split into smaller ones, each newly split > > > page should get its codetag. The original codetag is reused for these > > > pages but it's recorded as 0-byte allocation because original codetag > > > already accounts for the original high-order allocated page. > > > > Wouldn't it be possible to adjust the original's accounted size and > > redistribute to the split pages for more accuracy? > > I can't recall why I didn't do it that way but I'll try to change and > see if something non-obvious comes up. Thanks! Ok, now I recall what's happening here. alloc_tag_add() effectively does two things: 1. it sets reference to point to the tag (ref->ct =3D &tag->ct) 2. it increments tag->counters In pgalloc_tag_split() by calling alloc_tag_add(codetag_ref_from_page_ext(page_ext), tag, 0); we effectively set the reference from new page_ext to point to the original tag but we keep the tag->counters->bytes counter the same (incrementing by 0). It still increments tag->counters->calls but I think we need that because when freeing individual split pages we will be decrementing this counter for each individual page. We allocated many pages with one call, then split into smaller pages and will be freeing them with multiple calls. We need to balance out the call counter during the split. I can refactor the part of alloc_tag_add() that sets the reference into a separate alloc_tag_ref_set() and make it set the reference and increments tag->counters->calls (with a comment explaining why we need this increment here). Then I can call alloc_tag_ref_set() from inside alloc_tag_add() and when splitting pages. I think that will be a bit more clear. > > >