[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZD/XoBTqJBL2G+Dk@tpad>
Date: Wed, 19 Apr 2023 08:59:28 -0300
From: Marcelo Tosatti <mtosatti@...hat.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Christoph Lameter <cl@...ux.com>,
Aaron Tomlin <atomlin@...mlin.com>,
Frederic Weisbecker <frederic@...nel.org>,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
Russell King <linux@...linux.org.uk>,
Huacai Chen <chenhuacai@...nel.org>,
Heiko Carstens <hca@...ux.ibm.com>, x86@...nel.org,
Vlastimil Babka <vbabka@...e.cz>,
Michal Hocko <mhocko@...e.com>
Subject: Re: [PATCH v7 00/13] fold per-CPU vmstats remotely
On Wed, Apr 19, 2023 at 08:29:47AM -0300, Marcelo Tosatti wrote:
> On Wed, Apr 19, 2023 at 08:14:09AM -0300, Marcelo Tosatti wrote:
> > This was tried before:
> > https://lore.kernel.org/lkml/20220127173037.318440631@fedora.localdomain/
> >
> > My conclusion from that discussion (and work) is that a special system
> > call:
> >
> > 1) Does not allow the benefits to be widely applied (only modified
> > applications will benefit). Is not portable across different operating systems.
> >
> > Removing the vmstat_work interruption is a benefit for HPC workloads,
> > for example (in fact, it is a benefit for any kind of application,
> > since the interruption causes cache misses).
> >
> > 2) Increases the system call cost for applications which would use
> > the interface.
> >
> > So avoiding the vmstat_update update interruption, without userspace
> > knowledge and modifications, is a better than solution than a modified
> > userspace.
>
> Another important point is this: if an application dirties
> its own per-CPU vmstat cache, while performing a system call,
Or while handling a VM-exit from a vCPU.
This are, in my mind, sufficient reasons to discard the "flush per-cpu
caches" idea. This is also why i chose to abandon the prctrl interface
patchset.
> and a vmstat sync event is triggered on a different CPU, you'd have to:
>
> 1) Wait for that CPU to return to userspace and sync its stats
> (unfeasible).
>
> 2) Queue work to execute on that CPU (undesirable, as that causes
> an interruption).
>
> 3) Remotely sync the vmstat for that CPU.
Powered by blists - more mailing lists