All of lore.kernel.org
 help / color / mirror / Atom feed
From: Igor Mammedov <imammedo@redhat.com>
To: Tao Xu <tao3.xu@intel.com>
Cc: "ehabkost@redhat.com" <ehabkost@redhat.com>,
	"Liu, Jingqi" <jingqi.liu@intel.com>,
	"Du, Fan" <fan.du@intel.com>,
	"qemu-devel@nongnu.org" <qemu-devel@nongnu.org>,
	"jonathan.cameron@huawei.com" <jonathan.cameron@huawei.com>,
	"Williams, Dan J" <dan.j.williams@intel.com>
Subject: Re: [PATCH v12 06/11] numa: Extend CLI to provide memory latency and bandwidth information
Date: Fri, 11 Oct 2019 15:56:47 +0200	[thread overview]
Message-ID: <20191011155647.5b3fdf27@redhat.com> (raw)
In-Reply-To: <5bfe9d25-89a1-90a6-75fb-a6aecf4844c0@intel.com>

On Wed, 9 Oct 2019 14:39:46 +0800
Tao Xu <tao3.xu@intel.com> wrote:

> On 10/2/2019 11:16 PM, Igor Mammedov wrote:
> > On Fri, 20 Sep 2019 15:43:44 +0800
> > Tao Xu <tao3.xu@intel.com> wrote:
> >   
> [...]
> >> +struct HMAT_LB_Info {
> >> +    /* Indicates it's memory or the specified level memory side cache. */
> >> +    uint8_t     hierarchy;
> >> +
> >> +    /* Present the type of data, access/read/write latency or bandwidth. */
> >> +    uint8_t     data_type;
> >> +
> >> +    /* Array to store the latencies */  
> > specify units it's stored in
> >   
> >> +    uint64_t    *latency;
> >> +
> >> +    /* Array to store the bandwidthes */  
> > ditto
> >   
> >> +    uint64_t    *bandwidth;  
> > btw:
> > 
> > what was the reason for picking uint64_t for storing above values?
> > 
> > it seems in this patch you dumb down bandwidth to MB/s above but
> > store latency as is.  
> 
> Because I want to store the bandwidth or latency value (minimum unit) 
> that user input. In HMAT, the minimum unit of bandwidth is MB/s, but in 
> QAPI, the minimum unit of size is Byte. So I convert size into MB/s and 
> time unit is "ps", need not convert.
Just be consistent and store (user input) raw values for both fields
(i.e. B/s PS/s) and post-process them later to uint16_t.

> > and then in 9/11 build_hmat_lb you divide that on 'base' units,
> > where are guaranties that value stored here will fit into 2 bytes
> > used in HMAT to store it in the table?
> >   
> For HMAT spec, for a matrix of bandwidth or latency, there is only one 
> base (in order to save ACPI tables space). We need to extract base for a 
> matrix, but user input bandwidth or latency line by line. So after all 
> data input, we can extract the base (as in 9/11).
> 
> There is another benefit. If user input different but similar units, 
> such as "10ns" and "100ps", we can also store them. Only If user input 
> big gap units, such as "1ps" and "1000ms". we can't store them and raise 
> error.
No disagreement here,

but I suggest to move verification and base calculation from 09/11
into a separate patch (right after this one) and doing it at
numa_complete_configuration() time.
To store calculated base you can add a common_base field to
sub-table structure (HMAT_LB_Info) and use it when building ACPI
table without extra calculations.

> > if this structure should store values in terms on HMAT table it should
> > probably use uint16_t and check that user provided value won't overflow
> > at the time of CLI parsing.
> >   
> 



  reply	other threads:[~2019-10-11 14:09 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-09-20  7:43 [PATCH v12 00/11] Build ACPI Heterogeneous Memory Attribute Table (HMAT) Tao Xu
2019-09-20  7:43 ` [PATCH v12 01/11] util/cutils: Add qemu_strtotime_ps() Tao Xu
2019-09-20  7:43 ` [PATCH v12 02/11] tests/cutils: Add test for qemu_strtotime_ps() Tao Xu
2019-09-20  7:43 ` [PATCH v12 03/11] qapi: Add builtin type time Tao Xu
2019-10-15  6:22   ` Tao Xu
2019-09-20  7:43 ` [PATCH v12 04/11] tests: Add test for QAPI " Tao Xu
2019-09-20  7:43 ` [PATCH v12 05/11] numa: Extend CLI to provide initiator information for numa nodes Tao Xu
2019-09-30 11:25   ` Igor Mammedov
2019-09-20  7:43 ` [PATCH v12 06/11] numa: Extend CLI to provide memory latency and bandwidth information Tao Xu
2019-10-02 15:16   ` Igor Mammedov
2019-10-09  6:39     ` Tao Xu
2019-10-11 13:56       ` Igor Mammedov [this message]
2019-10-12  2:54         ` Tao Xu
2019-09-20  7:43 ` [PATCH v12 07/11] numa: Extend CLI to provide memory side cache information Tao Xu
2019-10-03 11:19   ` Igor Mammedov
2019-10-09  7:54     ` Tao Xu
2019-10-11 14:10       ` Igor Mammedov
2019-09-20  7:43 ` [PATCH v12 08/11] hmat acpi: Build Memory Proximity Domain Attributes Structure(s) Tao Xu
2019-10-03 13:44   ` Igor Mammedov
2019-09-20  7:43 ` [PATCH v12 09/11] hmat acpi: Build System Locality Latency and Bandwidth Information Structure(s) Tao Xu
2019-10-03 14:41   ` Igor Mammedov
2019-10-10  6:53     ` Tao Xu
2019-10-11 14:08       ` Igor Mammedov
2019-10-12  3:04         ` Tao Xu
2019-10-14  9:00           ` Igor Mammedov
2019-10-15  0:59             ` Tao Xu
2019-10-15  5:40               ` Tao Xu
2019-10-17 14:17                 ` Igor Mammedov
2019-09-20  7:43 ` [PATCH v12 10/11] hmat acpi: Build Memory Side Cache " Tao Xu
2019-10-04  8:01   ` Igor Mammedov
2019-09-20  7:43 ` [PATCH v12 11/11] tests/bios-tables-test: add test cases for ACPI HMAT Tao Xu
2019-10-04  8:08   ` Igor Mammedov
2019-09-21  1:39 ` [PATCH v12 00/11] Build ACPI Heterogeneous Memory Attribute Table (HMAT) no-reply
2019-09-21  1:53 ` no-reply

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=20191011155647.5b3fdf27@redhat.com \
    --to=imammedo@redhat.com \
    --cc=dan.j.williams@intel.com \
    --cc=ehabkost@redhat.com \
    --cc=fan.du@intel.com \
    --cc=jingqi.liu@intel.com \
    --cc=jonathan.cameron@huawei.com \
    --cc=qemu-devel@nongnu.org \
    --cc=tao3.xu@intel.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.