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 E9CDDC3064D for ; Tue, 2 Jul 2024 15:17:17 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 6B69B6B007B; Tue, 2 Jul 2024 11:17:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 666CB6B009B; Tue, 2 Jul 2024 11:17:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 530386B009C; Tue, 2 Jul 2024 11:17:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 32E596B009B for ; Tue, 2 Jul 2024 11:17:17 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id D85CE16030F for ; Tue, 2 Jul 2024 15:17:16 +0000 (UTC) X-FDA: 82295166072.17.568483E Received: from mail-yw1-f170.google.com (mail-yw1-f170.google.com [209.85.128.170]) by imf10.hostedemail.com (Postfix) with ESMTP id 15032C0023 for ; Tue, 2 Jul 2024 15:17:14 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wv1jRTT7; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 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=1719933413; 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=qddjwouc8RoAj7jr51rFqx0fiYtDCviRjv/0qU3grIo=; b=lFl04u3Voyq2r6o2Rv+VrGPJ+/8op6VYUwl2tXy8py2Ywzl8pqx0Z76JhXcr5yx2IRVltV SwCdFZE/KjOmHhabSedHfRbcYnM0JglteiNSa4yI9Wtoiac8C0loEp+yLfCQRESFZDV4cm YrWGingsxYqHAmk1XQqzzOUh9WKnBCc= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719933413; a=rsa-sha256; cv=none; b=pPheaE3ktL7o5vP+u/HVyzl8nKIV1lR12E/VxjgzJiAay14VBtBc29Ay7mxIcVtXoKnFJR fmfYZi8jFI6w6iPjoNkahyYlt+ltC1AmpD5tk5vpdTjH6EnfHNOl7wOJp93ugSBLNLnTEB 8Vc46cXaTEDbSeJj81njmAj0o1HS5Jw= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=wv1jRTT7; spf=pass (imf10.hostedemail.com: domain of surenb@google.com designates 209.85.128.170 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-yw1-f170.google.com with SMTP id 00721157ae682-64f2fe21015so17469177b3.3 for ; Tue, 02 Jul 2024 08:17:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719933434; x=1720538234; 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=qddjwouc8RoAj7jr51rFqx0fiYtDCviRjv/0qU3grIo=; b=wv1jRTT71nkcBPv2P1A/FYgoQPlXYES0FopBycXKftHig7NKPRh+ZQHa6VJOnd/udo qAWM6uSe+uaw3jeXZHD+gQuWEliDYFfkrf33l1aZ1uAItgYylf+Bkyf6L1BDQ1nwnkeB 2bQJInB4H2o0lo1mNqZI/icNRfIxXOUhy1kSmNj82homl7OLM4Z+tXZC2q9c+4b/8Rhl COyVE1tTK0R4fy51jhnrAhMpM4nDQz604p5bA3hgvDgbTcLaNcU6D4azjGZVxf+uSas+ k2yqAugmLUlfRHp4mHZfLvx0k52mhJqLwwK4C0fA52QPdzzC4SZcLmNUFgaWXf9g7/fo YqcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719933434; x=1720538234; 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=qddjwouc8RoAj7jr51rFqx0fiYtDCviRjv/0qU3grIo=; b=gec1tDe0OURXoNTzoFrc6YXeA7imLljXH+/LrsfQ4KTiwadSgFZzJdq49diHa/RkVm 20Cl890dbnoSdBlzdVGNaufLxc5xKSpvRW4xPQXoPAuYXaQelKK5pAtSgj5xONKO8eFJ dLf9AcCUxYOEXt8Wks84+VMHKDJuTMg7fRU45SRCJsWFZg2jZIMWfAHY1MTMIjYtH7ap iK6bR2qsZv+ewRi4lEIzPNbTn7krrEU64gqldu7sudKRd3vrYXT9bo2rnQFB3NQAayMW FA/UaPitu6TX0QGDmzC/PwHBZYURpCruWbf9HAm8wbWuJ3h/qy/kDd1rAo4NYPEShNfN MHMQ== X-Forwarded-Encrypted: i=1; AJvYcCXQMjuE5YHNzGBHcABY+y7qPn1C8ad+kQceB+ato2MwrACi3Tzo6it6CkxvS1ame7j0tF1h5LYEbMYmh7HJYNoLhTc= X-Gm-Message-State: AOJu0YweSRxSEFAAh23G1RpUNG6wM+onktCJrjSp5T8d/SzLLiJN2u3N zjOva+z/dPovlynzQMmcr1kmQ7khkrdPuxGcMcd875FfEMOUB8gCVV0A1f7ZdD3+h34vEUp6NW8 YOvFDhWQM2pXExvE7LUiqWdP2HCPbHMGYPoxN X-Google-Smtp-Source: AGHT+IHTVy9xRk6hLI42ekUGvCrTb7U3Xsmwg9IJIsH6OufqdQn7BwisVIKm95gEyqpji8U4ax/lBvGKgz5K5iZrHPU= X-Received: by 2002:a0d:eb89:0:b0:627:dfbd:3175 with SMTP id 00721157ae682-64c71144366mr108441827b3.10.1719933433867; Tue, 02 Jul 2024 08:17:13 -0700 (PDT) MIME-Version: 1.0 References: <20240614230504.3849136-1-surenb@google.com> <2a0ee369-12f9-401a-9179-82bd659ae201@suse.cz> In-Reply-To: From: Suren Baghdasaryan Date: Tue, 2 Jul 2024 15:17:01 +0000 Message-ID: Subject: Re: [PATCH 1/1] mm: handle profiling for fake memory allocations during compaction To: Vlastimil Babka Cc: akpm@linux-foundation.org, kent.overstreet@linux.dev, pasha.tatashin@soleen.com, souravpanda@google.com, keescook@chromium.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 15032C0023 X-Stat-Signature: emwq4ep4wjdd933kpye3gzsn1kttrcdk X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1719933434-533292 X-HE-Meta: U2FsdGVkX1/T5em0Y6PS4en0VqqyRQ7JroqS9IrRkzdh+2TEVOl3qz0Uyg0AlYZyioSjOaEmZ2cQKANvRSS8lpCvQM7/cAmbf8wFra+cK8m9Xm7UHfwYehZVaRsBazSQmZJDKPbWMa1fIDloHOgjdrUGBk/Db7UYPgv4izSxhxiNOXlfGLOd9Px42Q9/lymfRGYryYg7yi22KUnzOf8wPCiy46ba92EyqMNSktIQDbHgNLlNtPURClEF/ohrmKNNThkalMUfUFAx+rq2/H84YrktDZoU3onzunoqD7atvuOcfcReGmbHjlINRmIZ0+eTNwhOelQ641fxQlKClhDD7iOtLot9WRVmvN6G1IPa3sF9u2kYgf4H2h+83J9podvM3SoAS/1pzFdjOdS4JvUyHKc5sPqxYh88mWWDPbzeVbSSo4mpsLNX/j57OtSlKGM1AifmwSIHvv19TSVFN/IwytWAeNhuWxMvn9Vl3wyyukgkaO3MZoajOxIMwhcs6Z/xpOjQ/MFTwkqcmTE4m/L3jwUlL/+wj2jz21weXOfbklfgKAnJgJ71jwpN9liSGpZiPsk86aaUCbCdYYO9gYSc/QQ/xedp8I7KAbeADPqOzfop/ZuFFbGuG357D0gshZKXNokJPwL7yj4WjGTsqk6VxH9WLPEIj4JUnGaBWtsVSIcBIijgDFShtb0QMd7B/Sb9uS0jTBNQecyoUiQJUghLHFQQibEia8uPR+dlkrad5HM+x96YPgxabQ2jNHmKPJD9FP0U+SwkBfAtxYjQt5dIIomwGVcLXBTXhxEBqwxXtMb8wdG9e2EYY8lBqVtMLd3PLdlwjeLRGLgOwzerRvcX70P5HqeIbdFo48A0YFje9//QIVq7oLQDTQqBkmU4htWrH+/riTu2zRvvXExKI4bIrg3A1UIM+90MlgYQ2CrPTM3RxkYzR+3Y28d/zSNkogWPVSb6yz6cJyR5O7ZIx5J szRKaLny LTpAhs2LeoQm+mpKYhYGaOysokC9fciCw6ThcGZTHwUl8b1Wg8WxNrih9WpoaseV8d7Q4w8iWCQgUut2FgFN5m+0DgPUSIb4eCz5S7WptLrox3mZSyNWGEJDLSeeOVBjE1ENnAZaLRaz5BIhO0eSRC3QDSV5yt+Vd6qZOIyr2uN0F8r4= X-Bogosity: Ham, tests=bogofilter, spamicity=0.004430, 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 Tue, Jul 2, 2024 at 9:32=E2=80=AFAM Vlastimil Babka wro= te: > > On 6/30/24 9:17 PM, Suren Baghdasaryan wrote: > > On Mon, Jun 17, 2024 at 1:33=E2=80=AFAM Vlastimil Babka wrote: > >> > >> On 6/15/24 1:05 AM, Suren Baghdasaryan wrote: > >> > During compaction isolated free pages are marked allocated so that t= hey > >> > can be split and/or freed. For that, post_alloc_hook() is used insid= e > >> > split_map_pages() and release_free_list(). split_map_pages() marks f= ree > >> > pages allocated, splits the pages and then lets alloc_contig_range_n= oprof() > >> > free those pages. release_free_list() marks free pages and immediate= ly > >> > >> Well in case of split_map_pages() only some of them end up freed, but = most > >> should be used as migration targets. But we move the tags from the sou= rce > >> page during migration and unaccount the ones from the target (i.e. fro= m the > >> instrumented post_alloc_hook() after this patch), right? So it should = be ok, > >> just the description here is incomplete. > > > > Sorry for the delay with replying, Vlastimil. > > Yes, you are correct. Some of these pages are not immediately freed > > but migrated and during migration the destination gets charged for > > them. As a result these new counters should still read 0 most of the > > time except for some intermediate states. > > I can amend the description if this is considered important. > > The fix was merged to mainline already. Oh, didn't realize that. Ok, will have to keep it as is then. >