linux-kernel - Re: [PATCH V2] cgroup/rstat: Avoid thundering herd problem by kswapd across NUMA nodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 26 Jun 2024 15:07:55 -0700
From: Yosry Ahmed <yosryahmed@...gle.com>
To: Jesper Dangaard Brouer <hawk@...nel.org>
Cc: "Christoph Lameter (Ampere)" <cl@...ux.com>, Shakeel Butt <shakeel.butt@...ux.dev>, tj@...nel.org, 
	cgroups@...r.kernel.org, hannes@...xchg.org, lizefan.x@...edance.com, 
	longman@...hat.com, kernel-team@...udflare.com, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH V2] cgroup/rstat: Avoid thundering herd problem by kswapd
 across NUMA nodes

On Wed, Jun 26, 2024 at 2:35 PM Jesper Dangaard Brouer <hawk@...nel.org> wrote:
>
>
>
> On 26/06/2024 00.59, Yosry Ahmed wrote:
> > On Tue, Jun 25, 2024 at 3:35 PM Christoph Lameter (Ampere) <cl@...ux.com> 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 the
> >>>> best eventual solution. From the vmstats infra, we can learn that
> >>>> frequent async flushes along with no sync flush, users are fine with the
> >>>> '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.
>
> I implemented a variant using completions as Yosry asked for:
>
> https://lore.kernel.org/all/171943668946.1638606.1320095353103578332.stgit@firesoul/

Thanks! I will take a look at this a little bit later. I am wondering
if you could verify if that solution fixes the problem with kswapd
flushing?