From: Igor Mammedov <imammedo@redhat.com>
To: Tao Xu <tao3.xu@intel.com>
Cc: eblake@redhat.com, mst@redhat.com, xiaoguangrong.eric@gmail.com,
ehabkost@redhat.com, jingqi.liu@intel.com, qemu-devel@nongnu.org,
pbonzini@redhat.com, danmei.wei@intel.com,
karl.heubaum@oracle.com, rth@twiddle.net,
Markus Armbruster <armbru@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v3 4/8] Extend the command-line to provide memory latency and bandwidth information
Date: Tue, 2 Apr 2019 11:46:37 +0200 [thread overview]
Message-ID: <20190402114637.24cb44cc@redhat.com> (raw)
In-Reply-To: <ea1cf631-2c4c-9b66-c5d3-147d67181fab@intel.com>
On Tue, 2 Apr 2019 12:42:37 +0800
Tao Xu <tao3.xu@intel.com> wrote:
> On 2/6/19 6:11 PM, Igor Mammedov wrote:
> > On Thu, 31 Jan 2019 15:16:54 +0800
> > Tao Xu <tao3.xu@intel.com> wrote:
> >
> >> From: Liu Jingqi <jingqi.liu@intel.com>
> >>
> >> Add -numa hmat-lb option to provide System Locality Latency and
> >> Bandwidth Information. These memory attributes help to build
> >> System Locality Latency and Bandwidth Information Structure(s)
> >> in ACPI Heterogeneous Memory Attribute Table (HMAT).
> > Maybe instead of adding/using more globals since the rest of numa.c was
> > written so, it's time to introduce NumaMachine type which inherits
> > form base Machine and extends it with numa extensions.
> >
> > You don't have to refactor all old numa code for that (just the parts
> > you use in HMAT) and later we could gradually refactor the rest of
> > numa handling.
> >
> Hi Igor,
>
> I am sorry for replying after so long, because I am preparing the next
> version of patch and confusing about the implementation of NumaMachine.
> If NumaMachine inherits from Machine, and then the PCmachine and other
> platform machine inherits from NumaMachine (Implementation a)? Or
> PCmachine and other platform machine inherits from Machine
> (Implementation b)?
>
> Implementation a: Implementation b:
> Machine Machine
> │ │
> └── NumaMachine ├── NumaMachine
> │ │
> ├── PCMachine ├── PCMachine
> │ │
> └── none-PCMachine └── none-PCMachine
I'd imagine 'a', where none-PCMachine is arm/virt and spapr machines that
support numa today. The rest would inherit from plain Machine.
> And how about add numa.c's globals into MachineState? This may not
> change a lot.
That's another possible way, but it's polluting generic machine with
numa specifics about which only 3-4 boards care.
From my point of view it's a bit better then globals but not much.
> Looking forward to your reply.
>
> Tao
>
next prev parent reply other threads:[~2019-04-02 10:06 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-31 7:16 [Qemu-devel] [PATCH v3 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT) Tao Xu
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 1/8] hmat acpi: Build Memory Subsystem Address Range Structure(s) in ACPI HMAT Tao Xu
2019-02-06 9:05 ` Igor Mammedov
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 2/8] hmat acpi: Build System Locality Latency and Bandwidth Information " Tao Xu
2019-02-06 9:17 ` Igor Mammedov
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 3/8] hmat acpi: Build Memory Side Cache " Tao Xu
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 4/8] Extend the command-line to provide memory latency and bandwidth information Tao Xu
2019-02-06 10:11 ` Igor Mammedov
2019-04-02 4:42 ` Tao Xu
2019-04-02 9:46 ` Igor Mammedov [this message]
2019-04-02 19:23 ` Eduardo Habkost
2019-04-02 19:12 ` Eduardo Habkost
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 5/8] numa: Extend the command-line to provide memory side cache information Tao Xu
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 6/8] hmat acpi: Implement _HMA method to update HMAT at runtime Tao Xu
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 7/8] hmat acpi: move some function inside of the caller Tao Xu
2019-02-06 10:49 ` Igor Mammedov
2019-01-31 7:16 ` [Qemu-devel] [PATCH v3 8/8] acpi: rewrite the _FIT method to use it in _HMA method Tao Xu
2019-02-06 9:35 ` Igor Mammedov
2019-02-01 4:43 ` [Qemu-devel] [PATCH v3 0/8] Build ACPI Heterogeneous Memory Attribute Table (HMAT) no-reply
2019-02-06 10:51 ` Igor Mammedov
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=20190402114637.24cb44cc@redhat.com \
--to=imammedo@redhat.com \
--cc=armbru@redhat.com \
--cc=danmei.wei@intel.com \
--cc=eblake@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jingqi.liu@intel.com \
--cc=karl.heubaum@oracle.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.net \
--cc=tao3.xu@intel.com \
--cc=xiaoguangrong.eric@gmail.com \
/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.