Re: [Qemu-devel] [PATCH v4 07/11] hmat acpi: Build Memory Side Cache Information Structure(s) in ACPI HMAT

[Igor Mammedov]

On Mon, 10 Jun 2019 21:39:12 +0800
Tao Xu <address@hidden> wrote:

> On 6/7/2019 12:45 AM, Igor Mammedov wrote:
> > On Thu, 6 Jun 2019 11:00:33 +0800
> > Tao Xu <address@hidden> wrote:
> >   
> ...
> >>
> >> But the kernel HMAT can read othe Memory Side Cache Information except
> >> SMBIOS entries and the host HMAT tables also haven’t SMBIOS Handles it
> >> also shows Number of SMBIOS handles (n) as 0. So I am wondering if it is
> >> better to setting "SMBIOS handles (n)" as 0, remove TODO and comment the
> >> reason why set it 0?  
> > 
> > My understanding is that SMBIOS handles are used to associate side cache
> > descriptions with RAM pointed by SMBIOS handles, so that OS would be
> > able to figure out what RAM modules are cached by what cache.
> > Hence I suspect that side cache table is useless in the best case without
> > valid references to SMBIOS handles.
> > (I might be totally mistaken but the matter requires clarification before
> > we commit to it)
> >   
> 
> I am sorry for not providing a detailed description for Memory Side 
> Cache use case. I will add more detailed description in next version of 
> patch.
> 
> As the commit message and /Documentation/admin-guide/mm/numaperf.rst of 
> Kernel HMAT(listed blow), Memory Side Cache Structure is used to provide 
> the cache information about System memory for the software to use. Then 
> the software can maximize the performance because it can choose the best 
> node to use.
> 
> Memory Side Cache Information Structure and System Locality Latency and 
> Bandwidth Information Structure can both provide more information than 
> numa distance for software to see. So back to the SMBIOS, in spec, 
> SMBIOS handles point to the memory side cache physical devices, but they 
> are also information and not contribute to the performance of the 
> described memory. The field "Proximity Domain for the Memory" can show 
> the described memory.
> 
> I am wondering if this explanation is clear? Thank you.

I didn't manage to find a definite answer in spec to what SMBIOS entry
should describe. Another use of 'Physical Memory Component' is in PMTT
table and it looks to me that it type 17 should reffer to DIMM device.

But well, considering spec isn't clear about subject and that linux
kernel doesn't seem to use this entries lets use it without SMBIOS
entries for now. Like you suggested, lets set number of SMBIOS handles to 0
and drop num_smbios_handles so that user won't be able to provide any.


> "System memory may be constructed in a hierarchy of elements with 
> various performance characteristics in order to provide large address 
> space of slower performing memory cached by a smaller higher performing 
> memory."
> 
> "An application does not need to know about caching attributes in order
> to use the system. Software may optionally query the memory cache
> attributes in order to maximize the performance out of such a setup.
> If the system provides a way for the kernel to discover this 
> information, for example with ACPI HMAT (Heterogeneous Memory Attribute 
> Table), the kernel will append these attributes to the NUMA node memory 
> target."
> 
> "Each cache level's directory provides its attributes. For example, the
> following shows a single cache level and the attributes available for
> software to query::
> 
>       # tree sys/devices/system/node/node0/memory_side_cache/
>       /sys/devices/system/node/node0/memory_side_cache/
>       |-- index1
>       |   |-- indexing
>       |   |-- line_size
>       |   |-- size
>       |   `-- write_policy
> "
>