linux-kernel - Re: dm-crypt performance regression due to workqueue changes

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]

Message-ID: <ede7d32c-5668-a2dc-ca9-e4b56cdfb42@redhat.com>
Date: Mon, 1 Jul 2024 15:40:53 +0200 (CEST)
From: Mikulas Patocka <mpatocka@...hat.com>
To: Daniel P. Berrangé <berrange@...hat.com>
cc: Michal Prívozník <mprivozn@...hat.com>, 
    Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>, 
    Waiman Long <longman@...hat.com>, Mike Snitzer <snitzer@...nel.org>, 
    Laurence Oberman <loberman@...hat.com>, 
    Jonathan Brassow <jbrassow@...hat.com>, Ming Lei <minlei@...hat.com>, 
    Ondrej Kozina <okozina@...hat.com>, Milan Broz <gmazyland@...il.com>, 
    linux-kernel@...r.kernel.org, dm-devel@...ts.linux.dev, 
    users@...ts.libvirt.org
Subject: Re: dm-crypt performance regression due to workqueue changes



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