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 2252AE8FDAF for ; Tue, 3 Oct 2023 19:52:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 903CC8D008F; Tue, 3 Oct 2023 15:52:28 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 8B3FF8D0003; Tue, 3 Oct 2023 15:52:28 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7A3458D008F; Tue, 3 Oct 2023 15:52:28 -0400 (EDT) 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 6BF318D0003 for ; Tue, 3 Oct 2023 15:52:28 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 34D6014043A for ; Tue, 3 Oct 2023 19:52:28 +0000 (UTC) X-FDA: 81305197176.08.7DC98B7 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf02.hostedemail.com (Postfix) with ESMTP id 6E3218001D for ; Tue, 3 Oct 2023 19:52:26 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="sV4br/Cz"; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=yosryahmed@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=1696362746; 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=9sFl+PgZTi5H/tq/vNQ7bb3Je3y5ediHExPSrKbXhkc=; b=bMxpZXr/6k38IjwpQP/EggoBfLQxqjFJ96x8Z3j2Cqxl8IcYE/lS7y+5ye8eN/WVD4Kcf/ AGpW5iTBwKBhn0G0d1UIAVrvYbpAQRcofEJ7gWTmKVkM2r/4E/YP9elm0GfnKt5A5K/l9w Jp7LqCeKgHrEi1Q2NBCRXEOE1+SR+i4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1696362746; a=rsa-sha256; cv=none; b=LB6Td/bKBWv+k3/zTLBDC2UcljTyi8hgP4FnNIDTWd186vXPGauUrP4rpajakzqCNRXqkT cXXcXbC5tS156IfofS1Mvc47GHm1CVCU9TFFIb4azrwAMm6pn4+PNlS0GXBViXvwyr6u6J hpt6C2a5xUb/y0gHwIJJIgYZSO39b6o= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="sV4br/Cz"; spf=pass (imf02.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-991c786369cso226343966b.1 for ; Tue, 03 Oct 2023 12:52:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1696362745; x=1696967545; 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=9sFl+PgZTi5H/tq/vNQ7bb3Je3y5ediHExPSrKbXhkc=; b=sV4br/CzpICUoMI7p5uXW8P1/GKfmtAvmpmMuTK9Ly09KDAW9asEKWva86dNwOFbrS aVUy5coAHEa8mKT6YfCYvwhmlKB9BpW5OLZg3KHYoZvCXJQbNTPky5bC7FKUXpUcUebA JYBs0t+d1b0rmfo/FTgeN4K7Mvg2/80Z5YKe43E+66jWVBwx323A/BDx6mdt0pZZNXbe 7vxWohmBOKHciF6BUzaB8yosNpkLJZDqGpLn6iTsFqaHdJW1IYwr2/dGPzErs+xZ8uiW OhxaJ79+Qjn5N5dzEs8Uy20vvE6mDa7FHugsFkIbcTRft/QYreXrn1AAblpPcndB8CFB mxpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696362745; x=1696967545; 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=9sFl+PgZTi5H/tq/vNQ7bb3Je3y5ediHExPSrKbXhkc=; b=CJurFlG7iOQMginr3I6t9Gs1dggXhWHqCLSCYtm78A4QIRHZMdpZqrzsh7lbhpd4fD M6xOrEg9goUD3b7MGPltyWfRvwvmeQt6psR2AM7IMjGYu9Vg0bd2izZavMDTRryChARv 4uPEfcAFIyB8eeEcBgEV9CLNw8kZ+/1qoLhtbcajhGgt96r+lA7FUl8+/x/z/k31BdBZ fhW31Mq39m5Zvo6FLFzNR0+PIUCYw7UmR0u6u0RJ7qnuQ4qPOfHYM+RkRP1xgvXjx4ew ko0Tjcg/XjAKO9jDUclHrjCap6uO4gUzWQ22CEnTJnFlkMMXji56ffk9zCzzh3nb23ID gSAQ== X-Gm-Message-State: AOJu0YyNyQo9F7qISETJZd/87vaOWrIkVQAHuhcTfdq2eQbaVUG/l7iv qjCri4K32k61/n9JalKeED7SyHu9gca1hQsov0OQ0Q== X-Google-Smtp-Source: AGHT+IGwxXJCirR+VKpaM868xSVnDoCsjqHYCyDOfreMvQLZ/FRz2tiYTixuwDIhUm7h8JfAE1H/9yRjEIZvuJoTeL4= X-Received: by 2002:a17:906:8465:b0:9ae:6bef:4a54 with SMTP id hx5-20020a170906846500b009ae6bef4a54mr166358ejc.3.1696362744926; Tue, 03 Oct 2023 12:52:24 -0700 (PDT) MIME-Version: 1.0 References: <20230922175741.635002-1-yosryahmed@google.com> <20230922175741.635002-3-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 3 Oct 2023 12:51:49 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] mm: memcg: normalize the value passed into memcg_rstat_updated() To: =?UTF-8?Q?Michal_Koutn=C3=BD?= Cc: Andrew Morton , Shakeel Butt , Johannes Weiner , Michal Hocko , Roman Gushchin , Muchun Song , linux-mm@kvack.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 6E3218001D X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: ww7zq6fcfh51a5fa4qwxmwgtq4497yqt X-HE-Tag: 1696362746-100418 X-HE-Meta: U2FsdGVkX19evlSNiUAWGbAGTtk0W/AuJyV35FsCFOwzfhNU6YQkNv5lm4rfoNDwLL9YHEWzKkn7Plt0VluB0H41gVJDbq78E5KrzCNoqNpNbeqVFTDQEAHEm7413OI1SlQeVuAeCIhWM2PiwdTYmMWd9NDafrNOPiAIDyx9rfhs9deQMJ+Q9PARXyJPBryf1dDTHgs42Jq4ypjjaMVKdX9PWaGN69+F90HuDoe8dtQMGYmIwp+4GGSs2T34aAO+PAIlhFJjdaNHchmhinlGwme8GWcAWxLTO4Tf9L19DKkYdgpxYloJT5WqhpwOJRCgyc4sXNQoscVshVHwE6hkoSUGLXnfVhJEfC/UE4FjneMmCFX7FJHNNgUvlmn1aveHYwLK30/VboQZQqq2EGv04CDGylGF7PGpR7y+MfJpFD3qmd3bd1DoOpE8a8d5Xn6n9iiWK7AHkainLZ2pMA0ueqSzfMICRajDtmbIMX3aZvP4/XAwZ1z7o/M6qqP6hDABOEmXjBvBlo0Y5tHm/ITGNAykYCJgWdV4xeA9+ovNRow9ZmkZUbbDMpjsAEwo38QcK/oi4PLkoIucSRpXmxwIqkccylMsEa9la1soMzhedz0zfVliBYYOxcvhgRrwJKM4dxz4BIlajJvPxXZ5p3anv9H5ovdpLK32SwQUoRS7YkBwGwxskPB3ans64lOGAJ9gd9nsRo9qcrqpy2sq06vVSTvc39oJ3/CywUeH+oNb/evLHplnip1pQxjIZiaJ9r95zKpweeRObfeO5l2d0uyPrabHfidCvYK+4OTe2ieUM7geQyX1zJIQkTwaI6bVGU4DmKOmbUB6O5cmdWlqC+KUY17Xk2YHxpfrnxg198FwVa58NxsJPD1kNoB2ShwZZoQGNG0cttUbvfSbMUiIJygVmTj1gC3ZkK8mWvZxz7pzXl/SvALCcETVHtLxQ2Tv+KH/DVfhmKSm524EPwbeKSN J5Ck5XbO JDvLZ8PTB/UA2Qp1o0rXJ27oKt6Av+cY34JYn8zkbBxZED4RQBraxqJd9XgPNbj51dYntIYCf1rpjkoELMAlgpTSUQfVC3mM8j+ETpFg/a4dXjQyYs7cvvQ2eccoiCbxZQxKldsE5fv70KQaprWQhWSzcNAqMxw5KwzGaP7DXdNV/pTclmShywfiVXQnsz4OepJCdzXJui1p4karCqkMxhj2+9LRQUguPcx1vFkM5GsnG9Gj+7vfPnWgQKIzE1WtXZCP85X9XwOf3/NCIJ8NRYl1sUd6TaPcBiWdfjf+QOM84en1CDm9FByldrd2qsX/bQfGbwpmyxGP+tzXD0Py3uzt02yRaJOkFgdcT 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: On Tue, Oct 3, 2023 at 11:22=E2=80=AFAM Michal Koutn=C3=BD wrote: > > On Fri, Sep 22, 2023 at 05:57:40PM +0000, Yosry Ahmed wrote: > > memcg_rstat_updated() uses the value of the state update to keep track > > of the magnitude of pending updates, so that we only do a stats flush > > when it's worth the work. Most values passed into memcg_rstat_updated() > > are in pages, however, a few of them are actually in bytes or KBs. > > > > To put this into perspective, a 512 byte slab allocation today would > > look the same as allocating 512 pages. This may result in premature > > flushes, which means unnecessary work and latency. > > > > Normalize all the state values passed into memcg_rstat_updated() to > > pages. > > I've dreamed about such normalization since error estimates were > introduced :-) > > (As touched in the previous patch) it makes me wonder whether it makes > sense to add up state and event counters (apples and oranges). I conceptually agree that we are adding apples and oranges, but in practice if you look at memcg_vm_event_stat, most stat updates correspond to 1 page worth of something. I am guessing the implicit assumption here is that event updates correspond roughly to page-sized state updates. It's not perfect, but perhaps it's acceptable. > > Shouldn't with this approach events: a) have a separate counter, b) > wight with zero and rely on time-based flushing only? (a) If we have separate counters we need to eventually sum them to figure out if the total magnitude of pending updates is worth flushing anyway, right? (b) I would be more nervous to rely on time-based flushing only as I don't know how this can affect workloads. > > Thanks, > Michal