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 00465EED615 for ; Thu, 12 Sep 2024 16:12:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 748266B0095; Thu, 12 Sep 2024 12:12:37 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F8456B0096; Thu, 12 Sep 2024 12:12:37 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 59AA86B0098; Thu, 12 Sep 2024 12:12:37 -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 3A1156B0095 for ; Thu, 12 Sep 2024 12:12:37 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 855FCC0E38 for ; Thu, 12 Sep 2024 16:12:36 +0000 (UTC) X-FDA: 82556579112.18.6368AC7 Received: from mail-ed1-f49.google.com (mail-ed1-f49.google.com [209.85.208.49]) by imf01.hostedemail.com (Postfix) with ESMTP id 9CB3940012 for ; Thu, 12 Sep 2024 16:12:34 +0000 (UTC) Authentication-Results: imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="uAWo/yhJ"; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.208.49 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=1726157450; 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=QiQyIF1mvxSjqMyhPNS2IVuiQwAu3H/w1r54T2zJLTM=; b=Yy0j6eXO/yd9TGCwVtQcECXM6e2cmPBAO5B0VmBFjzlAGgqqTaNrUz4OTd47PuRbz9FrxH MTeUpsM3VCJ4Onos30zFmiwbcopDwOp+tekp+FDIRU8V4LPJniRkf5EBjuRJYffV3zFbk9 ilg4Le8BzNgmHFuE51RoYY+NzSjMOzo= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1726157450; a=rsa-sha256; cv=none; b=HBIhkniPC/hDFF9HEszW2TZ+98ZukKqIJ5cGmDWYzGcy31EcdhyYcl77oCnmMKa1q+C4LX Uq3KK12Po5rrCH7G+MupEGrAkhunWd83G80uQP7ymRDLNLGSnZ36gSYqTh+JBRq03dXVsy jXneMrr7O8Ao23839PVSLvsTWvtY138= ARC-Authentication-Results: i=1; imf01.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="uAWo/yhJ"; spf=pass (imf01.hostedemail.com: domain of surenb@google.com designates 209.85.208.49 as permitted sender) smtp.mailfrom=surenb@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ed1-f49.google.com with SMTP id 4fb4d7f45d1cf-5c24374d8b6so20265a12.1 for ; Thu, 12 Sep 2024 09:12:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1726157553; x=1726762353; 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=QiQyIF1mvxSjqMyhPNS2IVuiQwAu3H/w1r54T2zJLTM=; b=uAWo/yhJBNabZravrkOeONw53MdB09C50lhw6DR/bvYIddiNtB5IfgugmMOLOJJVVS TtPv1p02Peo+K55SJUNBWFTbPZ7cUvHlO4ozVmPZ5IOrjYElKnL3Bo2PSlo/lWS2UgSD CP0v1H3TWkns5iX91ZeNu6ElBpPEKlSwgwpvZz8cRlGTFB1rRwxHJyrtT7qmzxoM90TQ Q9s8It4IJf76m9JJvGxFIUhhrSscwUyx3md+dSat8MXXGNxZ6Qo40ce8vTsmY+k73xzY 6wR68olTX8SlESj181r/KQgoOyYup8ynAcnCVJyX6JpabJaafuH8Xwt13GfveruT+25e nXcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726157553; x=1726762353; 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=QiQyIF1mvxSjqMyhPNS2IVuiQwAu3H/w1r54T2zJLTM=; b=iik5rv/P9ev6kJhoZi+wO9pR40057GeKGicq84Nxrt5pgMmwcZmTc1XE4luKRzwd2v MEVd5z+NWt5XKwF2i2arUYl02F/a8eQSUjOHuA73ncUzxlMxOArfT/KVPp1HGwbImbLK fHGnK5n8TNJXcK4Zn/Ww0beslOYh+sWWdA63bl3OoU56QJpvWRrdexTE/VcxC/dR4wnu JaLLYY7AHhawnHrSF+XFqcwxHjECGFsrPee/s/rJI2XszzxADgZiK1edyNwuKtUx0nym dJ8lRa7qwidDunUL+JExDJkspmUcx9Vc7Hbx+8BV7PvjgOs47uTRu8Ja+CMqP5NOK1eo NRpw== X-Forwarded-Encrypted: i=1; AJvYcCWlZrGNrB67D+Azsbs+/m1ZoSnFmlMDQxGl9eaEySZjqmliWR+uP1e1iygHZGObs33orCmHHtK2zQ==@kvack.org X-Gm-Message-State: AOJu0YxHU62Vc0Qb/ES2He+vuznZTMzKpnAazbTjXmtAwr3N6TAytOq4 SKTP4z03cKhcSAPul1aomMZ1ZPElV/l7LbpY/oRm3oV9tCYcb5pupOb9zfts2ngMQeG/Qqz0vg1 I5aW5O3R1EPdTwaL8k4SLA5aWoDMxW4NoDfFO X-Google-Smtp-Source: AGHT+IF+EtVAWErpzQLsJU9lzROtq87V+bVYpIsCmWHQQvWO7HFhIFw3/0JzawddfQWxIl+EB/VhgRDZ1jDo9tla5Q4= X-Received: by 2002:a05:6402:348d:b0:5c0:aad5:43db with SMTP id 4fb4d7f45d1cf-5c4146155d7mr261554a12.4.1726157552469; Thu, 12 Sep 2024 09:12:32 -0700 (PDT) MIME-Version: 1.0 References: <20240912022740.6125-1-00107082@163.com> In-Reply-To: <20240912022740.6125-1-00107082@163.com> From: Suren Baghdasaryan Date: Thu, 12 Sep 2024 09:12:20 -0700 Message-ID: Subject: Re: [PATCH] Add accumulated call counter for memory allocation profiling To: David Wang <00107082@163.com>, Yu Zhao Cc: kent.overstreet@linux.dev, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 9CB3940012 X-Stat-Signature: qoyd8tr7wdx7kdbq91bpfr7q5gnuua7z X-Rspamd-Server: rspam09 X-Rspam-User: X-HE-Tag: 1726157554-316897 X-HE-Meta: U2FsdGVkX198Rjrm3vGOprd9ntgKiLOGroFqoApWXarBSpY3IfFDqrYOVZ9Hl4pHNhQBNFO+gpCrBQU/Rr2xrIpj+NLvSBtiEDdVifwGG4lhsr4nhLqLH+ZFq/VfRGnrS8g0owXpUEPE4OYseEicBGTEoMv62z5ATwgm3iYFQUsfprccTefWuneXV2911qrUjOnonYUV4xXaBQRNtxQ9rOOn0g9t8ED5uPM25kdeme4WO7iTzqbv+rf3QsILLu7J4TtA7LahdTTHjtyZaaTLgS9ewV1tnq+MSDGaxOq0YyGAb42ygrpqJSQWadOHcFuYxzQdQoDE/r7/jG0AbevaxbHP0vIsJpILWiMx+z0FodvMJEqiTOE9soDrOm07uxqRChFm0udikVel0+qujFOzupGEvIql8Tg9t5eAH+J02cOY7iNWQTY5XvX8sTw7t5Pc2SDTzvWB+1o5dV76dLrV2xGSx8Zve8W636RtrxOKWcrLdnKI+edo0pY6fwWK6u9uQ+C0WZB89+pE+5gsi+INWMmqz2NCYMEY3TqmWVGjNEDLBqe/gG1/xw12hf7SRG1lTKxunRP1qlCGbiTi/n3gzzgtPBUONFqZRQ9NIgr685gr1hDiuYTvyANJhumpsuYpeS+9+aV4R2XZf5azr8+OTypTw7wdQ9vGglykYpqBaQA22y2hW8rRhai3bPzEjxc17hUE4z65iURF3PNHJxhCykSLNLslOxs1w/AtOcyTHRG1qlVPw1bpeqrszeQdFU0hA3d2bzDFHdj+DN90kxxpFwPCTLSAyFaOI1NypL+98exvEEVs8frV3fawtMGLwvEmMge32gnfmsiqtrgmZss/WkQ6wMKuYakZACcP3L/jH/9rmWHuHLwefvahJpN4Fl/U/OjYSyDcKxByNEcxorD+CzSXF6pnZEPCUk87JR2Lt9w8NsmowN71WpaBgb6uuY/XdWymfBKx5rh4JObpeMZ rfXZ3Ib1 w5fE8DV6m9pW5+7ebHZzu21fUtdj6y31ZKiNfnqlS+0OdfaqIanKWO4ZkE3H3BjvjAnoZlMAwfXAEhgdEEFo1KmRmyHCn2FqOc0D4F7TbP3fPIVdZdGfpd6xyKqHM5keLWqCrAdMVoFMKrcSmqWKxO2dPqNiDbOHyg02OzHnEJPx2d04Ez/L2/LpMJAiQX/iP4S9fnPXYNAwiz1BmgGA4YecH/uSVaZz0K2hnT6HcYDbPaRDSVc6M5TAGxB2LXd+6SUqgUmIu2D7Okk9PqKHyZxF+Di2OmD85CO8KfaZiPLN99hUd47B1f9sO+1wTGH9j0KJww7DYmHoHhzQQ3ScWLzHYFSYCxlQ7Fffg X-Bogosity: Ham, tests=bogofilter, spamicity=0.078629, 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 Wed, Sep 11, 2024 at 7:28=E2=80=AFPM David Wang <00107082@163.com> wrote= : > > At 2024-07-02 05:58:50, "Kent Overstreet" wro= te: > >On Mon, Jul 01, 2024 at 10:23:32AM GMT, David Wang wrote: > >> HI Suren, > >> > >> At 2024-07-01 03:33:14, "Suren Baghdasaryan" wrote= : > >> >On Mon, Jun 17, 2024 at 8:33=E2=80=AFAM David Wang <00107082@163.com>= wrote: > >> >> > >> >> Accumulated call counter can be used to evaluate rate > >> >> of memory allocation via delta(counters)/delta(time). > >> >> This metrics can help analysis performance behaviours, > >> >> e.g. tuning cache size, etc. > >> > > >> >Sorry for the delay, David. > >> >IIUC with this counter you can identify the number of allocations eve= r > >> >made from a specific code location. Could you please clarify the usag= e > >> >a bit more? Is the goal to see which locations are the most active an= d > >> >the rate at which allocations are made there? How will that > >> >information be used? > >> > >> Cumulative counters can be sampled with timestamp, say at T1, a monit= oring tool got a sample value V1, > >> then after sampling interval, at T2, got a sample value V2. Then the = average rate of allocation can be evaluated > >> via (V2-V1)/(T2-T1). (The accuracy depends on sampling interval) > >> > >> This information "may" help identify where the memory allocation is un= necessary frequent, > >> and gain some better performance by making less memory allocation . > >> The performance "gain" is just a guess, I do not have a valid example. > > > >Easier to just run perf... > > Hi, > > To Kent: > It is strangely odd to reply to this when I was trying to debug a perform= ance issue for bcachefs :) > > Yes it is true that performance bottleneck could be identified by perf to= ols, but normally perf > is not continously running (well, there are some continous profiling proj= ects out there). > And also, memory allocation normally is not the biggest bottleneck, > its impact may not easily picked up by perf. > > Well, in the case of https://lore.kernel.org/lkml/20240906154354.61915-1-= 00107082@163.com/, > the memory allocation is picked up by perf tools though. > But with this patch, it is easier to spot that memory allocations behavio= r are quite different: > When performance were bad, the average rate for > "fs/bcachefs/io_write.c:113 func:__bio_alloc_page_pool" was 400k/s, > while when performance were good, rate was only less than 200/s. > > (I have a sample tool collecting /proc/allocinfo, and the data is stored = in prometheus, > the rate is calculated and plot via prometheus statement: > irate(mem_profiling_count_total{file=3D~"fs/bcachefs.*", func=3D"__bio_al= loc_page_pool"}[5m])) > > Hope this could be a valid example demonstrating the usefulness of accumu= lative counters > of memory allocation for performance issues. Hi David, I agree with Kent that this feature should be behind a kconfig flag. We don't want to impose the overhead to the users who do not need this feature. Thanks, Suren. > > > Thanks > David > > >