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 C11E4E77188 for ; Tue, 14 Jan 2025 18:48:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 52FB928000C; Tue, 14 Jan 2025 13:48:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 4DF8A280003; Tue, 14 Jan 2025 13:48:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3808628000C; Tue, 14 Jan 2025 13:48:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 16A36280003 for ; Tue, 14 Jan 2025 13:48:28 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id CB27E160303 for ; Tue, 14 Jan 2025 18:48:27 +0000 (UTC) X-FDA: 83006943054.20.48EAAA8 Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) by imf14.hostedemail.com (Postfix) with ESMTP id D20B410000F for ; Tue, 14 Jan 2025 18:48:25 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Mif3bLAk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736880505; 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=PWsWL6P0HXmNw6CTXE9SYyPdMsWl2KnUffsyavzbzEI=; b=XkZVtFWG4+F2y/KjuDctrbmGRgeSuaBSUfOkbNhtQvQJY0nRh0Kwfecw2Dz71UJXIoIiBA Dpvj6dpISSVzMErFSWycjnmwN+02FQm3V7Td5iN/GNg2GDsnpJOoUvMakZrxBIsIbdzh/2 anVNAgZdJIY6NwvptMKyEGiyqH4VKLw= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736880505; a=rsa-sha256; cv=none; b=ZUW2IK7k9Gs2c1/5D69ntHyaPUTcPwGST9lqVuPwopT/tsR3R/PBBsXJjgRZgppow4hgBo +mFsu+hM288Gi6jAPOcVTr/fZ3UUcyQeRyPNk57vbtsTNMQKVNvX7iaA/GZd7/MgQKHrOO D+xkY8NOcNB4FivJtn6lAfJ579X8g74= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Mif3bLAk; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf14.hostedemail.com: domain of surenb@google.com designates 209.85.160.169 as permitted sender) smtp.mailfrom=surenb@google.com Received: by mail-qt1-f169.google.com with SMTP id d75a77b69052e-4678c9310afso271791cf.1 for ; Tue, 14 Jan 2025 10:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736880505; x=1737485305; 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=PWsWL6P0HXmNw6CTXE9SYyPdMsWl2KnUffsyavzbzEI=; b=Mif3bLAkVqaWeETHjsyZxkJ28FBfCq/u98BJ6oqoN0qeVAsIZXn7cqsPbBhJ9xGZdd 7iAbJepLht3edHMS9ZzWbsZZLzU3ohExFqBDEbmpyX4ClB45w3zcAkk4v4VFI6SWmzKV 5Jj7E8WxEd+6oIMuaJekvvCG4UGB/Z89IxFco51bIp9EQJQ1K2KO+IeFnq2sE5sYG569 9Yh7ackf/YfCdR3eAcr/08JpH1U7dIo6dFsai2BgVoyu2XsiYWT2Y6MRJdgHD+9O37mb Dh/oMBw4swvbnMzWYvRqo23pe/7sauxnM6IlCyxxn9nonaXYmiBTFN8lbQcHG2n6iAey YW3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736880505; x=1737485305; 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=PWsWL6P0HXmNw6CTXE9SYyPdMsWl2KnUffsyavzbzEI=; b=pa4qWMmPjnFKPsvoAtEuvqQtA/kp4c3NmOTF2PxNFl7qvccowEZmwtd0B3Wemztx1c FvgtZwGi1qEMOt7lurZ2FEPG2Awpf5+YB0fOFOMmTcfcTptt2szWR6NfHxRG9a+VaPzu soc4jQ8VeNMp2tZ7wTaDOSa3ruJWlWnuGqKd04DMUsU30jV7NWt5uavSrBgNWUmN4xQW KCr6N35yaBgH0AmSEvyNE1ZqGJhQwt/FF/sZSULHXisOnn9Ynh2cqvAJXff3RkTpFpZv 1r5XfrmkMHyyz7ZEtUwUMgv9UdRzjdCuLh4hhTAGYUN7aBcDatzpDb7kh7m8LuTJYah8 7Q7A== X-Forwarded-Encrypted: i=1; AJvYcCWYngUkDisgyWbT61nuiHfO0BpDhHFG5fp3DYZ+GinkaFR3nD+BeLWFClIMkBUnDsvrQLNzF0ea1A==@kvack.org X-Gm-Message-State: AOJu0YyHcOQxfGpNiaI0MNBU7m/0+wfyZnOdh0UtsGrOmzOLZoXc8WjM F8AyzQmSNI/vTCRFt5pAtYl+VfbcnZ61ev4IC07n7GGmnViZGGQJdap+2n95Ccjv4RFIinIua8V gcSNPPlnVdCO1M+Zc8LPgCaX7MrkOruxtyP+D X-Gm-Gg: ASbGncs/D7IGxHRBqerBOE14sbqCVyWgX7B7BNwo3ujIgDsVMjgNaKXIkHfrrbtjroc 26+VArtKV8Kw/NBSYi4XgbcigNlmWOkpgowrnphTx/mw2gzSmD+bS+kZaXK3zgoV5lZfL X-Google-Smtp-Source: AGHT+IEVZpn9rYuZy5c/qIPYgg48lvSn0SQan6xJePcf9sR/yMhyCWw/Q0nUBFP7VXs09UF1lx/tWaD+W63fta4AFkU= X-Received: by 2002:a05:622a:647:b0:46c:7d66:557f with SMTP id d75a77b69052e-46df56789f8mr48221cf.8.1736880504581; Tue, 14 Jan 2025 10:48:24 -0800 (PST) MIME-Version: 1.0 References: <20250106112103.25401-1-hao.ge@linux.dev> <48f208b6.32ab.19455c70dbe.Coremail.00107082@163.com> <254a4857.b2b.19458d0dbc2.Coremail.00107082@163.com> <213ff7d2.7c6c.1945eb0c2ff.Coremail.00107082@163.com> <961050d.3c22.19462e1e30d.Coremail.00107082@163.com> In-Reply-To: <961050d.3c22.19462e1e30d.Coremail.00107082@163.com> From: Suren Baghdasaryan Date: Tue, 14 Jan 2025 10:48:13 -0800 X-Gm-Features: AbW1kvZzlfZpqrbOgN2Rs4O2x2X5-Fag2GXfmuitLXib_9zNdnW9Z7psuDqR6BA Message-ID: Subject: Re: memory alloc profiling seems not work properly during bootup? To: David Wang <00107082@163.com> Cc: kent.overstreet@linux.dev, Hao Ge , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Hao Ge , Alessio Balsini , Pasha Tatashin , Sourav Panda Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: s5suix1h9nuiqq1jffeibwpt4ufqzq6f X-Rspamd-Queue-Id: D20B410000F X-Rspam-User: X-Rspamd-Server: rspam01 X-HE-Tag: 1736880505-757575 X-HE-Meta: U2FsdGVkX18zNcM8X3Vi24Z5qogRttsRi6Kdh86J6X9OknQx7+ESsOlkiY5eCv1RcO5gQgl8HW1X+0S1QSq85u5HUda3RvAoGy0s3O/H/Cy0hCxk6P0Gt4Bj3k30Gbt9TWBq8LdXjWHmBETNCHoekN9O9byfCX9t3NJbta8k7zCM5JDy263zwtIYxVnmluQWykrknnHbI4QLkanzmU/86OFA4ZDQjsDbsWvtDdiR7g0KPvON83QT81D3MKNkjGCi8d0N6L3QVz6b4w8XfGrgpNODNSMe4ehWY/Wl+wn8M7XdfDC4kmTD6o9Md+LrfT7NY9u2K6zmivTDyIb+aGib5VL1icL++2VpIZ9y7I5lzhmXO6bRzHk0hqN2zGY7GFYlPP20hYcs473uPNHhlU1e6dVXhdmb8oT7EPYQDSZofSB2VUMUTP5xFhdd5hwSELTMhIMa0QiZQMtYSOecDOK69WRDxU9NBqiHKLC2Hl6cHCvE6nXGiIemkb6lrCcpPSuTKg/ETIh4lVOtM3qgqnB8c0LRZUj3BZ43EbFFa04X837DdtQvABA57nRHA1R3QPsLvbmsaha6j0f+y7GTh2iHBVVMSy/dRW0GTtgD1llBNEgoUvCQx8f0/jHLZadsjuz9PbkJ7otJM+ao0Kfg/9mlbqVJI8zySdAFoXUyWXdKsRDmxHmmOutADnqpzqTFZv+rZ0YY4jKCgopq7LRpRDI9uhc7lKZiiPtO8hWw8mitSO2rlBKXPHrljKFu4eml2WxXcmuaVmKEXh2X6Ws1PXVhLlS0lmBXY83GA1QrRvP7CHKWAX7qAQa7GEKSX+V2+SWxpfSwukzVooUyDmKQWh/6vdzKDMjvgKjKJev+MalLeA7YQc5MGQTkj0jz0NIY2tCt78b2lrz47o8T0dH/SzE/zChZiRDEJPqJmIvQRJSruJQLfwarEHW/THO/rSGMgWNmoobrSXVM42q+2sKZWqu J7rwDjtE gsFi7PdVGQpEdxJApar9v7PKjIl4mnForFo2P6IWqwc0evU1MTPvj7g/c+HDhps1OdAmDg/YYPzx79yy35SIr6GtIbKnZh15cpNJoU8/MhegDHKkj2UPnqC2Wd9+Zap4scMuS3ml2M9EdmaexsXm1uziRqMvDb0BrCpxpIyLHy+vYX8FlpsFAXCVx/pfK7A1cGty4DdXVUM103iCEhjYBztvSysC3VrPvMG3/RZEuSStAvIpmi9nMOYg2qx5m68SApup6iGIrrZuAT3G8exjBqnwnA6LfW0/uclWt0Jf+JOEslOti/S+lfjAfBZ6xQLLRp9SRFiPrc/M7Sxd9zF8V6mSdIAU6vX74S9hyZrpKpQi2p5a6E6jPGUVciQ== X-Bogosity: Unsure, tests=bogofilter, spamicity=0.480250, 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 Mon, Jan 13, 2025 at 7:36=E2=80=AFPM David Wang <00107082@163.com> wrote= : > > Hi, > > > At 2025-01-14 05:56:23, "Suren Baghdasaryan" wrote: > >On Mon, Jan 13, 2025 at 12:04=E2=80=AFAM David Wang <00107082@163.com> w= rote: > >> > >> Hi, > >> > >> More update, > >> > >> When I boot up my system, no alloc_percpu was accounted in kernel/sch= ed/topology.c > >> > >> 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 > >> 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 > >> 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 > >> 612 1 kernel/sched/topology.c:1961 func:sched_init_num= a 1 > >> > >> And then after suspend/resume, those alloc_percpu shows up. > >> > >> 996 14 kernel/sched/topology.c:2275 func:__sdt_alloc 39= 5 > >> 996 14 kernel/sched/topology.c:2266 func:__sdt_alloc 39= 5 > >> 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 39= 5 > >> 12388 24 kernel/sched/topology.c:2252 func:__sdt_alloc 39= 5 > >> 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70= <--- > >> 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70= <--- > >> 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70= <--- > >> 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70= <--- > >> 612 1 kernel/sched/topology.c:1961 func:sched_init_num= a 1 > >> > >> I have my accumulative counter patch and filter out items with 0 accum= ulative counter, > >> I am almost sure the patch would not cause this accounting issue, but = not 100%..... > > > >Have you tested this without your accumulative counter patch? > >IIUC, that patch filters out any allocation which has never been hit. > >So, if suspend/resume path contains allocations which were never hit > >before then those allocations would become suddenly visible, like in > >your case. That's why I'm against filtering allocinfo data in the > >kernel. Please try this without your patch and see if the data becomes > >more consistent. > > I remove all my patch and build a 6.13.0-rc7 kernel, > After boot up, > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domai= ns > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa > > And after suspend/resume, no change detected: > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domai= ns > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa > > I also build a image with accumulative counter, but no filter. > > After boot up: > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domai= ns 2 > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 80 > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 80 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 80 > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 80 > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 0 <= ---this *0* seems wrong > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 0 > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 0 > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 0 > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1 > > And then suspend/resume: > 64 1 kernel/sched/topology.c:2579 func:alloc_sched_domai= ns 17 > 896 14 kernel/sched/topology.c:2275 func:__sdt_alloc 395 > 896 14 kernel/sched/topology.c:2266 func:__sdt_alloc 395 > 96 6 kernel/sched/topology.c:2259 func:__sdt_alloc 395 > 12288 24 kernel/sched/topology.c:2252 func:__sdt_alloc 395 > 0 0 kernel/sched/topology.c:2242 func:__sdt_alloc 70 > 0 0 kernel/sched/topology.c:2238 func:__sdt_alloc 70 > 0 0 kernel/sched/topology.c:2234 func:__sdt_alloc 70 > 0 0 kernel/sched/topology.c:2230 func:__sdt_alloc 70 > 512 1 kernel/sched/topology.c:1961 func:sched_init_numa 1= > > Reading the code, those allocation behaviors should be tied together: > if kzalloc_node at line#2252 happened, then alloc_percpu at line#2230 sho= uld also happened. Hmm, ok. Looks like early calls to alloc_percpu() are not being registered somehow. Could you please share your cumulative counter patch with me? I'll try to reproduce this locally and see if I can spot the issue. > > kernel/sched/topology.c > 2230 sdd->sd =3D alloc_percpu(struct sched_domain *); > 2231 if (!sdd->sd) > 2232 return -ENOMEM; > ... > 2246 for_each_cpu(j, cpu_map) { > ... > 2252 sd =3D kzalloc_node(sizeof(struct sched_doma= in) + cpumask_size(), > 2253 GFP_KERNEL, cpu_to_node(j)); > ... > 2257 *per_cpu_ptr(sdd->sd, j) =3D sd; > > > But somehow during bootup, those alloc_percpu in kernel/sched/topology.c:= __sdt_alloc were missed in profiling. > (I am not meant to sell the idea of accumulative counter again here, but = it dose help sometimes. :). > > >Thanks, > >Suren. > > > > > >> > > Thanks > David