qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus


From: Daniel P . Berrangé
Subject: Re: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus
Date: Wed, 31 Jan 2024 08:56:47 +0000
User-agent: Mutt/2.2.12 (2023-09-09)

On Wed, Jan 31, 2024 at 02:54:19PM +0800, Zhao Liu wrote:
> On Wed, Jan 31, 2024 at 10:47:29AM +0530, Ani Sinha wrote:
> > Date: Wed, 31 Jan 2024 10:47:29 +0530
> > From: Ani Sinha <anisinha@redhat.com>
> > Subject: Re: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus
> > 
> > On Wed, Jan 31, 2024 at 9:27 AM Zhao Liu <zhao1.liu@intel.com> wrote:
> > >
> > > Hi Ani,
> > >
> > > On Wed, Jan 31, 2024 at 08:19:06AM +0530, Ani Sinha wrote:
> > > > Date: Wed, 31 Jan 2024 08:19:06 +0530
> > > > From: Ani Sinha <anisinha@redhat.com>
> > > > Subject: [PATCH v2] pc: q35: Bump max_cpus to 1856 vcpus
> > > > X-Mailer: git-send-email 2.42.0
> > > >
> > > > Since commit f10a570b093e6 ("KVM: x86: Add CONFIG_KVM_MAX_NR_VCPUS to 
> > > > allow up to 4096 vCPUs")
> > > > Linux kernel can support upto a maximum number of 4096 vCPUS when 
> > > > MAXSMP is
> > > > enabled in the kernel. At present, QEMU has been tested to correctly 
> > > > boot a
> > > > linux guest with 1856 vcpus and no more both with edk2 and seabios 
> > > > firmwares.
> > >
> > > About background, could I ask if there will be Host machines with so
> > > much CPUs? What are the benefits of vCPUs that far exceed the number
> > > of Host CPUs?
> > 
> > Yes HPE has SAP HANA host machines with large numbers of physical
> > cores and memory. For example QEMU was tested on a system with 3840
> > cores.
> 
> Thanks! For such large system, does the vCPU need the CPU affinity, or
> just let them run free on the Host's physical cores?

It depends what you are trying to achieve. The tradeoffs for guest
placement on small systems still pretty much apply on large systems
too. There may be factors which alter the balance for the tradeoffs,
but the theme is still determined by what the guest owner requires
and what the host owner wants to achieve.

Strict host:guest CPU affinity will give the guest a deterministic
amount of host CPU time, and lowest latencies. It is wasteful of
host resources though, because if a guest CPU is idle, a different
guests' CPU can't use that host CPU time. So letting guests run
freely across host cores and overcommiting CPUs will maximize
utilization but give non-deterministic timeslices & latency to
guests.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|




reply via email to

[Prev in Thread] Current Thread [Next in Thread]