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 A23AEC2BBCA for ; Tue, 25 Jun 2024 22:59:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 29EE56B0096; Tue, 25 Jun 2024 18:59:51 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 24E766B0099; Tue, 25 Jun 2024 18:59:51 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0EFD56B009A; Tue, 25 Jun 2024 18:59:51 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E4F096B0096 for ; Tue, 25 Jun 2024 18:59:50 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 8C28B8081F for ; Tue, 25 Jun 2024 22:59:50 +0000 (UTC) X-FDA: 82270930140.16.4309987 Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf11.hostedemail.com (Postfix) with ESMTP id AD5C540023 for ; Tue, 25 Jun 2024 22:59:48 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BAMuizDz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1719356371; 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=4nufzVyDas6rqXanqk2DFPV+HJQhWvNDqqsfFSssBLc=; b=tsWL6swBm2tJzD5v6DMIk4bY7IVVDMFgZMoGCG7pebY/9TA76aob3DguyDmZU9lfhgR4LM nfMW5E5dZF1/dxQAubVok5yE/yMV1IkaR26LSw1tZ+dSFyI5LGZCCrJ1Q/BmjOVqiLCtie cZDcJXSCcA2rw4wAyj42rSMEZRc1PgQ= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1719356371; a=rsa-sha256; cv=none; b=UBB/kmNJm1ZCpD6vYirAD7OdUXJ6WjtnQTtAd3EzQUXBdTy2ahxr5XAmmj+UOsOmbEZ268 /BxBETfbpIkrQxy48ZENWcKlhLgDFl75sM2OfdC+avG5rjtmX1f5g8NBepscJxCkaBWlSs IHO8Bk5DfRTbwRHiBpep+AVzUkGOysg= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=BAMuizDz; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf11.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=yosryahmed@google.com Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-a724b9b34b0so356593566b.1 for ; Tue, 25 Jun 2024 15:59:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1719356387; x=1719961187; 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=4nufzVyDas6rqXanqk2DFPV+HJQhWvNDqqsfFSssBLc=; b=BAMuizDz5QnIFWWSRzVRm1huCmw1KSH3MOIyIi1yo6K4Vo5PKTSGOWA7AiDM98Qg8B RUWcRxif4hVYAe3zEYZfaS9GVcI8E9/Z9TGiMyXHa/Ko5CgdaOQH5UuWiqcUq8qACaua gOrhRLsBLDTh2FsoEh8kgwFlDWGa+ujn0d04xmzr4RMZRCtIzrzjzP9wyGkAQ0UbX9m5 32vGfLzk97NOViGl47MDi5BiR8sk8op7WOnoHffrwVJDokKXPqJiC0x80BYgly5cJAfv kwKEkqwJZCncWmGofHhWH4L68bo+iRzzK22Rbid5enQzI7GiB+A+X6yCtbJDohsfWKJq 0gNA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719356387; x=1719961187; 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=4nufzVyDas6rqXanqk2DFPV+HJQhWvNDqqsfFSssBLc=; b=g7tPQqGhqp4BjBD/9970asqfzJM32YGupOYNgllgLNVInaLAec9ViKef0VNmdDafWi HcZhd6g3QdTGJM3o5eRuG+5MnmdcHgGbJ/hqyy5WuK8uadppE16Ft6FeJ/bRFRJcXiVo YfqQ6m1iW5/5p4nmPrHxsL68PseLtfHYsDhG2y4aXlVnHB+H4xZarjE3fGRRHkGwxwP/ RuaFj9FVHfcGRWF1Ldfu9b1Gxqq1wFjigYbCVUL6DtsnGm7hJdkSIwEAdc3gsNwAyG2/ vVYt04IRrF1WDbbXiGtMF31jW54mu6Ze8WbGHdHkLy9i3LMtXEqVhhQEr8ptDZBWcrfS hBSw== X-Forwarded-Encrypted: i=1; AJvYcCUXQbt0P4/LU2bxJ21+AN4at5Ed/avi52vvWx6LBNCmKe1obycKhQ2L1EynCT05R092D3KP0b9t6u65A2twDzeXJkA= X-Gm-Message-State: AOJu0Yxdh9p8KD1ANixcGzoYMs/ig7g9m6b76ES13H+T+kshjgkUG8SF yLyVrMgQQG6P9sVqlaPcsXU2oo6LUZH9mr/Y4LQozwOZHYKTAdKaItRUPvIGCwYow6eBu/nj6gC Rzu+8IgUN0GXHd1Xrq6o2/ufRcVw02sScZfwA X-Google-Smtp-Source: AGHT+IH/dDKhmlHal0QbDpSAnlMkS3U3pY+fmF7rZOA5u540GMB1xG2BZwZsKTdBAW+WPZDRIGqL8k4sWqeHNFO8TvI= X-Received: by 2002:a17:907:c786:b0:a6f:48b2:aac5 with SMTP id a640c23a62f3a-a7245b6dbe0mr547974966b.15.1719356386530; Tue, 25 Jun 2024 15:59:46 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yosry Ahmed Date: Tue, 25 Jun 2024 15:59:09 -0700 Message-ID: Subject: Re: [PATCH V2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes To: "Christoph Lameter (Ampere)" Cc: Shakeel Butt , Jesper Dangaard Brouer , tj@kernel.org, cgroups@vger.kernel.org, hannes@cmpxchg.org, lizefan.x@bytedance.com, longman@redhat.com, kernel-team@cloudflare.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AD5C540023 X-Stat-Signature: atzb5ejxi9woz4ix7aqxngt791gta8zk X-Rspam-User: X-HE-Tag: 1719356388-519485 X-HE-Meta: U2FsdGVkX1/kf/9r2rkgf41bXertRRMLZGGEhAiSgeYUHJHZIUuMCHC4y/kn0qnY1tCpeqIpDlWb8vIT17dTtPdGNMN9FjfFKQDNKlreeNyCIaVpYJ3Lhe0F6Pdt1+fyknEkEftZPL2OM/uv7teRzM6TA66+cYAwyrgDBTRThYtgFDtOdetezg1hzzwzxcorD0Bku20bShdIGtUTKvWKFp6HGMt53FaMj6cHDkAVHNz9X4D3UDLBQF+POIJkd4dhI8spRC1PcbfvNr57naaI4Ehr4yMCWf3BkPYYszemD21zbjwPJcEPB5jB6gq/pPzHKk0ihBuHGCUpqI0Ttn+eP1KD/4ejRXCmDUzOy7gLVBEvZyqQxDvHjBeCXxGaVApZgmaAiBfa+tk2xIvRzmJKWlvzeiibmzE7VVNKfv6IrI9nt3MJXGfdDRpqe+/zH7o+pGw4Gwl2IFrNqbKysgYFBsjPvOewxs8ToffqJOYDMxYLVh+AJPnd7MdlL3wg7ZDJm8ux1nVapUZLrQ3eS88CoeqxqndYT3fatH0ioZ8E/OBizMQUtAjyfpyivS/jnKhDNC6UKYTbFPGaVE0wMBXfVVBeXCAfxyVnRrhL0lSuzSja6J58TjzpYntUsaF7RXb4BJmn0ZpuDTAqB7rqA2DPSKfvPBGjJ7wGkV5jZPQAqQEieXkHr/ebRGcgngocCAQOz/SCueRD1aDST+tJ+CFdjBCLahweGT2ick9u6BBK8ST/17JmULMdkRztmmIsQEJHTasC/Qg8CmL/0w/lQtn4w6HlF8joDFeJoN+/CWuE1p2xNT5Jd+FzZg5rYtiOjYavjdGnm4mu/MHoGSXDIbkOhk+0KoTA+cegWNOUJEVgThkN+vPFE69GKjpJ1djFLsW2AMj+D/OBntgW+uyjk4CvI2f5SbS7wI/AxbD4uaIaICZmp/SBwABoS3gzp8Z4+YwdE0EwGz2lDkmk4UJsghg 6yn1X2lt nr+7CSIX+xH1hPzEvMwDQ5sakYQ9MCrBUVLcRVj6cWclN4rpLL/Qttqy8GICps+g4/FzO50Ly2fjD5ItghgmPxQ9+blPgBldhBvtbPAJO3c5iU3FsF68EwjhEnyHz6WJWtFm1oKEMaSxqcpxpQzlEEBCVJNtR/V9AyTkDWW1SagV+lTkesYr16Cq1KsXzn4CLbgXD8BOH5+Enktbf4kneFyo5tp064Ulym4sr X-Bogosity: Ham, tests=bogofilter, spamicity=0.376537, 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, Jun 25, 2024 at 3:35=E2=80=AFPM Christoph Lameter (Ampere) wrote: > > On Tue, 25 Jun 2024, Yosry Ahmed wrote: > > >> In my reply above, I am not arguing to go back to the older > >> stats_flush_ongoing situation. Rather I am discussing what should be t= he > >> best eventual solution. From the vmstats infra, we can learn that > >> frequent async flushes along with no sync flush, users are fine with t= he > >> 'non-determinism'. Of course cgroup stats are different from vmstats > >> i.e. are hierarchical but I think we can try out this approach and see > >> if this works or not. > > > > If we do not do sync flushing, then the same problem that happened > > with stats_flush_ongoing could occur again, right? Userspace could > > read the stats after an event, and get a snapshot of the system before > > that event. > > > > Perhaps this is fine for vmstats if it has always been like that (I > > have no idea), or if no users make assumptions about this. But for > > cgroup stats, we have use cases that rely on this behavior. > > vmstat updates are triggered initially as needed by the shepherd task and > there is no requirement that this is triggered simultaenously. We > could actually randomize the intervals in vmstat_update() a bit if this > will help. The problem is that for cgroup stats, the behavior has been that a userspace read will trigger a flush (i.e. propagating updates). We have use cases that depend on this. If we switch to the vmstat model where updates are triggered independently from user reads, it constitutes a behavioral change.