Re: dm-crypt performance regression due to workqueue changes

[Mikulas Patocka <mpatocka@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2209 bytes --]



On Mon, 1 Jul 2024, Daniel P. Berrangé wrote:

> On Mon, Jul 01, 2024 at 02:48:07PM +0200, Michal Prívozník wrote:
> > On 6/30/24 20:49, Mikulas Patocka wrote:
> > > 
> > > 
> > > On Sun, 30 Jun 2024, Tejun Heo wrote:
> > >>
> > >> Do you happen to know why libvirt is doing that? There are many other
> > >> implications to configuring the system that way and I don't think we want to
> > >> design kernel behaviors to suit topology information fed to VMs which can be
> > >> arbitrary.
> > 
> > Firstly, libvirt's not doing anything. It very specifically avoids doing
> > policy decisions. If something configures vCPUs so that they are in
> > separate sockets, then we should look at that something. Alternatively,
> > if "default" configuration does not work for your workflow well,
> > document recommended configuration.
> 
> Actually in this particular case, it is strictly speaking libvirt.
> If the guest XML config does not mention any <topology> info, then
> libvirt explicitly tells QEMU to set sockets=N,cores=1,threads=1.
> That matches QEMU's own historical built-in default topology.
> 
> None the less, my advice for mgmt applications using libvirt would
> likely be to explicitly request sockets=1,cores=N,threads=1. This
> is because it gives slightly better compatibility with unpleasant
> software that applies licensing / subscription rules that penalize
> use of many sockets, while being happy with any number of cores.
> 
> 
> Either way though, the topology is a lie when the guest CPUs
> are not pinned to host CPUs, so making performance decisions based
> on this is unlikely to yield the desired results. Historically the
> cores vs sockets distinction hasn't seemed to make much difference
> to guest OS performance, as the OS' haven't made significant
> decisions on this axis. Exposing threads != 1 though has always been
> a big no though, unless strictly pinning 1:1 guest:host CPUs, as that
> has had notable impacts on scheduling decisions.
> 
> With regards,
> Daniel

I think there should be some way how to tell the guest kernel "the vCPUs 
are free-floating, the topology is a lie", so that it can stop making 
incorrect decisions based on the fake topology.

Mikulas