From: "Michael S. Tsirkin" <mst@redhat.com>
To: "Denis V. Lunev" <den@virtuozzo.com>
Cc: Eduardo Habkost <ehabkost@redhat.com>,
Denis Plotnikov <dplotnikov@virtuozzo.com>,
pbonzini@redhat.com, rth@twiddle.net, qemu-devel@nongnu.org,
rkagan@virtuozzo.com
Subject: Re: [Qemu-devel] [PATCH] i386: turn off l3-cache property by default
Date: Wed, 29 Nov 2017 06:17:40 +0200 [thread overview]
Message-ID: <20171129061258-mutt-send-email-mst@kernel.org> (raw)
In-Reply-To: <2cd31202-27c3-983f-85a9-6814ff504706@virtuozzo.com>
On Tue, Nov 28, 2017 at 11:20:27PM +0300, Denis V. Lunev wrote:
> > There's one thing I don't understand in your test case: if you
> > just found out that Linux will behave worse if it assumes that
> > the VCPUs are sharing a L3 cache, why are you configuring a
> > 8-core VCPU topology explicitly?
> >
> > Do you still see a difference in the numbers if you use "-smp 8"
> > with no "cores" and "threads" options?
> >
> This is quite simple. A lot of software licenses are bound to the amount
> of CPU __sockets__. Thus it is mandatory in a lot of cases to set topology
> with 1 socket/xx cores to reduce the amount of money necessary to
> be paid for the software.
This answers the first question but not the second one.
If the answer to the second one is negative, then I don't understand why
changing the default makes sense.
I would expect qemu by default to be as close to emulating a physical
system as possible. If one has to deviate from that for some workloads,
that is fine, but probably not a good default.
--
MST
next prev parent reply other threads:[~2017-11-29 4:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-24 13:26 [Qemu-devel] [PATCH] i386: turn off l3-cache property by default Denis Plotnikov
2017-11-28 18:54 ` Michael S. Tsirkin
2017-11-28 19:50 ` Paolo Bonzini
2017-11-28 20:05 ` Eduardo Habkost
2017-11-29 4:56 ` Roman Kagan
2017-11-28 19:58 ` Eduardo Habkost
2017-11-28 20:20 ` Denis V. Lunev
2017-11-28 21:13 ` Eduardo Habkost
2017-11-29 1:57 ` Gonglei (Arei)
2017-11-29 5:55 ` rkagan
2017-11-29 6:01 ` Gonglei (Arei)
2017-11-29 5:20 ` Longpeng (Mike)
2017-11-29 6:01 ` Roman Kagan
2017-11-29 7:38 ` Longpeng (Mike)
2017-11-29 10:41 ` Eduardo Habkost
2017-11-29 11:58 ` Longpeng (Mike)
2017-11-29 13:35 ` Roman Kagan
2017-11-29 17:09 ` Eduardo Habkost
2017-11-29 17:15 ` Paolo Bonzini
2017-11-30 6:28 ` Roman Kagan
2017-11-30 9:26 ` Longpeng (Mike)
2017-11-29 5:46 ` Roman Kagan
2017-11-29 10:25 ` Eduardo Habkost
2017-11-29 4:17 ` Michael S. Tsirkin [this message]
2017-11-29 6:25 ` Roman Kagan
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171129061258-mutt-send-email-mst@kernel.org \
--to=mst@redhat.com \
--cc=den@virtuozzo.com \
--cc=dplotnikov@virtuozzo.com \
--cc=ehabkost@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rkagan@virtuozzo.com \
--cc=rth@twiddle.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.