Re: [PATCH v7 00/13] fold per-CPU vmstats remotely

[Marcelo Tosatti <mtosatti@redhat.com>]

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.