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 A30C7C3DA49 for ; Tue, 16 Jul 2024 17:21:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1486D6B007B; Tue, 16 Jul 2024 13:21:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F8A36B0085; Tue, 16 Jul 2024 13:21:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F02306B0089; Tue, 16 Jul 2024 13:21:03 -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 D10E76B007B for ; Tue, 16 Jul 2024 13:21:03 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 541F512072C for ; Tue, 16 Jul 2024 17:21:03 +0000 (UTC) X-FDA: 82346281206.08.6C78710 Received: from mail-pf1-f178.google.com (mail-pf1-f178.google.com [209.85.210.178]) by imf04.hostedemail.com (Postfix) with ESMTP id 76E6F40005 for ; Tue, 16 Jul 2024 17:21:01 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=vimeo.com header.s=google header.b=BJc0KSmd; dmarc=pass (policy=reject) header.from=vimeo.com; spf=pass (imf04.hostedemail.com: domain of davidf@vimeo.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=davidf@vimeo.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1721150430; a=rsa-sha256; cv=none; b=ruPbLoYvXVaLK77Y4ghcw39ybQcTGRLf+ZGvpAu6I/Y9QC9g568wVVTvPwlUvuKx3nwk9b L4R6ZGLR/n/NV2n8LOqSblF7oqLejnHJ8kU3MencyiblfQsjBl7SZFuekVJgmil9FTEZel QK8LVJtTLFLWHYBp4c4EQHVYpSU2zSA= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=vimeo.com header.s=google header.b=BJc0KSmd; dmarc=pass (policy=reject) header.from=vimeo.com; spf=pass (imf04.hostedemail.com: domain of davidf@vimeo.com designates 209.85.210.178 as permitted sender) smtp.mailfrom=davidf@vimeo.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1721150430; 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=1sv+QNc/DGMhPMVsZ2FxSdhckTqknm0RzzQv130owTc=; b=eoZ6np86v2HCpQdax5KSERLQ7sF8fS0rOPmAz4Lnujrrm1d/U4cRtEr+qaRA9FaFyCwd2R PyP/tikcZIeGXM3iLboVAW2dsk8Hs3l0vPBQSpqt3/GQfpgRrT0LugO8TkXs4M9BkMqt1u U79kHBe5xIGq7ReFnyggbCNqF2XxVgQ= Received: by mail-pf1-f178.google.com with SMTP id d2e1a72fcca58-70b2a0542c2so5466649b3a.3 for ; Tue, 16 Jul 2024 10:21:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimeo.com; s=google; t=1721150460; x=1721755260; 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=1sv+QNc/DGMhPMVsZ2FxSdhckTqknm0RzzQv130owTc=; b=BJc0KSmdJomaw5fZboMVxj5dHzO4nN4LuIth/zKQ8ja6ZgioQz7NhntZRY6/NRfM3U DNoOYfjqi+c8lxy1D9hc/p+a0LRIwHMfiFWUeL+XN1saPFSfin8VHMWQDavUdwj5Ap3F azNSZTSlorQwKn7McJUNXhl7osnSQCffIDog4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721150460; x=1721755260; 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=1sv+QNc/DGMhPMVsZ2FxSdhckTqknm0RzzQv130owTc=; b=p0HsGFFczWVZYy0+Mjbexn2ZHqOw/JTb5tE7cZQzlQq0m+DDMHdY5hnRwK2LgtQdMt K05kMUqyyB4lUgEYEMXCZpV+d4kKBfQQ/su/riNiu/BjrILs/V9NpPhqflGaiXbOKX1g oPG3rJHEcmLVYiZlymfaqL6XLTY3DguzW0IVhs24ZIF8L228zMRJHvsNnaGu1BtAqrCt SWnUB9wKldYGj0nr5gyhAbxdJfdsCm0Pdld4fm9sdFxTDrfw0FVmiMfVdAPzNf5uz/WD NFov7c0G84B0qvSobpowAJ5H570zOpGEvZkSfkiVlKZWnM7WXl/rYw5L+l4ukSVg/frP gCHQ== X-Forwarded-Encrypted: i=1; AJvYcCXY9tbYW66tIhmxg77iPHn6DQFxrU9DBXs0V9buboNeS9+QeOVxoPD2jKtaLYFhNMucuoRc4FmJ7LlgbaBmykO9rWY= X-Gm-Message-State: AOJu0YziLOcncZPPD9j3YVpjUB9u+y/WD2zOZr4Aw8NV54o97rkGn6aP rNnlbfeR4iHqMuTQVrJEeYovHRzUdjMZmCoUrOgkxHSyau6oSVk7J5y0LZoKXxxVB7BBqpEgMwp WsoQ0p0T70aEAWPq4SWxOtq0nWLlwleQ3AGLMgA== X-Google-Smtp-Source: AGHT+IE0jogasMR5Vo1zc09nO8WrQEH9BAm8Vis6rzWXoOwDzxBtbsrDWTNwvTcelBY4lZmxg6D9GIcINCHKQHMTUNA= X-Received: by 2002:a05:6a20:430b:b0:1c0:f594:198c with SMTP id adf61e73a8af0-1c3f11f7552mr3997701637.11.1721150460103; Tue, 16 Jul 2024 10:21:00 -0700 (PDT) MIME-Version: 1.0 References: <20240715203625.1462309-1-davidf@vimeo.com> <20240715203625.1462309-2-davidf@vimeo.com> In-Reply-To: From: David Finkel Date: Tue, 16 Jul 2024 13:20:48 -0400 Message-ID: Subject: Re: [PATCH] mm, memcg: cg2 memory{.swap,}.peak write handlers To: Roman Gushchin Cc: Tejun Heo , Michal Hocko , Muchun Song , Andrew Morton , core-services@vimeo.com, Jonathan Corbet , Shuah Khan , Johannes Weiner , Zefan Li , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, Shakeel Butt Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 76E6F40005 X-Stat-Signature: 6md3d7hpt8dy4zigkbyh85gm7uytizn4 X-Rspam-User: X-HE-Tag: 1721150461-130899 X-HE-Meta: U2FsdGVkX1++fhiJDQcDYDX2OZRUL89JYmfvVoxCOKHrDUMl0Rc6dRu6+SUy7voaqhoWmfSB71jE0mvPq511h5yEEV9l/gzE/KQxKKtEAW5rTNQnTSGYp4JGhkvBLX2f7DIN0vJGezIhLCXMHgajzGlO9ojmHcTvQUEysnpM2NxqZ2Nxjn3nkESG3cmGksOcPSchUzJzhYp62BsaXZDD4LdJkBPgK1e7QyDeT5zhpQ5mbQSszgRy+LMGy/TS/OQ0ErdfL7ddv+UJS1VVausmSrs475EA4p3Mst2dsh0CV55q5692cqeL3nVbkG4eemcPKd4O6UBwj3LAYj5FzLjJEsL3WBJRRu4725DvrpZTwJdKaqmPZwOMcIjppTyxk2q74oaH5/8vqCHFcy+0pb2ntTehOuTaktld0hsG5qg3riKSMpHhOpkPIIlpD/iD14oJresXl8Itqrkr8HPrhI9k3zaa6JibQiRIVaemwmLIfRQwA3RaZKIxeDnps8zT77vYWo5U23Hw5a4QlgN92btnNTb0IhXOkdcfyIqzc2lT7YGIAbyzTM/2oxHlX1nKZ+qXgjDg4fOb60hYluSPEtO9XGqn46ULojJJ9v6r8Ok3HOwn0DLysALOn3weshLvOZgffxednDJJKc1v3B2/XEcdeLkQslJfAmW/mnS/1q8r7lr73Hl8Ukcq5zrv46IezYtxPP5xVZJEhSgJns7092VoMZ0sCil4GEDdpq2mkP3LHX6SDZMCOCds3BBXGkDRS/q5s6h5zKeI3G/XzqxsCXrursVtVck918eNu16u+6XwpsR9Tt4jfSXxgRJNRuA5rOGb0CVinNzw34jFuJ4zgrSWM0A2A8qL2GwR5HtYI1VSiNf6I9sb/PQWTQNBRLG0ed9CvwSMNlYRmK8/TpCOgt/Ds1m8iQ7a4CFIdEobxjUn1IqSK+v06svv9+infstajohjhk3uAuvOFIuZKbKn1+E DDWTX0S4 2ym4vfLgRa0G/EEcD93y+ljrL55guQPa3swD1xQKbn0qDdnhdSn7Yi3Ntv95qS0zlvblFnYTNeCF32YbfE3iQjc4rvBG7rkb6T+AYSFq4I/7TmoHbI5swcCa1Bf+zA2NnWRVIdbiZn4s8N78o+0Nayt6Y0DFjKeM24U7m 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 Tue, Jul 16, 2024 at 1:01=E2=80=AFPM Roman Gushchin wrote: > > On Tue, Jul 16, 2024 at 06:44:11AM -1000, Tejun Heo wrote: > > Hello, > > > > On Tue, Jul 16, 2024 at 03:48:17PM +0200, Michal Hocko wrote: > > ... > > > > The removal of resets was intentional. The problem was that it wasn't c= lear > > who owned those counters and there's no way of telling who reset what w= hen. > > It was easy to accidentally end up with multiple entities that think th= ey > > can get timed measurement by resetting. > > > > So, in general, I don't think this is a great idea. There are shortcomi= ngs > > to how memory.peak behaves in that its meaningfulness quickly declines = over > > time. This is expected and the rationale behind adding memory.peak, IIR= C, > > was that it was difficult to tell the memory usage of a short-lived cgr= oup. > > > > If we want to allow peak measurement of time periods, I wonder whether = we > > could do something similar to pressure triggers - ie. let users registe= r > > watchers so that each user can define their own watch periods. This is = more > > involved but more useful and less error-inducing than adding reset to a > > single counter. > > It's definitely a better user interface and I totally agree with you rega= rding > the shortcomings of the proposed interface with a global reset. But if yo= u let > users to register a (potentially large) number of watchers, it might be q= uite > bad for the overall performance, isn't it? To mitigate it, we'll need to = reduce > the accuracy of peak values. And then the question is why not just poll i= t > periodically from userspace? FWIW, as a stop-gap, we did implement periodic polling from userspace for the system that motivated this change, but that is unlikely to catch memory-usage spikes that have shorter timescales than the polling interval. For now, we're keeping it on cgroups v1, but that's looking like a long-term untenable position. Thanks, --=20 David Finkel Senior Principal Software Engineer, Core Services