[Libosinfo] [osinfo-db PATCH 3/3] workload: Example for particular use case - SAP HANA

[Martin Kletzander]

On Tue, Nov 20, 2018 at 03:59:19PM +0000, Daniel P. Berrangé wrote:
>On Sat, Nov 17, 2018 at 01:06:13AM +0100, Martin Kletzander wrote:
>> This is an example of what information workloads should ultimately express.
>> This is not a comprehensive definition of what SAP HANA needs for functioning,
>> just a few things I dug out from the web.  But it contains various types of
>> settings that might be useful for workloads.  For example the hugepage size as
>> that is not something which is definite, the optimal size varies on the
>> workload.
>>
>> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
>> ---
>>  data/workload/example.com/sap-hana.xml.in | 29 +++++++++++++++++++++++
>>  1 file changed, 29 insertions(+)
>>  create mode 100644 data/workload/example.com/sap-hana.xml.in
>>
>> diff --git a/data/workload/example.com/sap-hana.xml.in b/data/workload/example.com/sap-hana.xml.in
>> new file mode 100644
>> index 000000000000..afc1216d41b3
>> --- /dev/null
>> +++ b/data/workload/example.com/sap-hana.xml.in
>> @@ -0,0 +1,29 @@
>> +<libosinfo version="0.0.1">
>> +<!-- Licensed under the GNU General Public License version 2 or later.
>> +     See http://www.gnu.org/licenses/ for a copy of the license text -->
>> +  <workload id="http://example.com/sap-hana">
>> +    <short-id>sap-hana</short-id>
>> +    <_name>SAP HANA</_name>
>> +    <derive-from id="http://example.com/high-perf"/>
>> +  </workload>
>> +
>> +  <!--
>> +      these are features, can be just feature strings, but I just went with putting them in a bit more structured manner
>> +  -->
>> +  <features>
>> +    <hugepages size="1" unit="G"/>
>
>I guess SAP HANA is an x86_64-only application, so not criticial here, but
>in general i wonder how this works from a cross-arch POV. Every arch has a
>different set of huge page sizes it can support.
>

My guess as well.  I just dug some of the info somewhere, but I don't have much
experience with it.

>> +    <nic>passthrough</nic>
>> +    <io>native</io>
>> +    <disk cache="none"/>
>
><nic> and <disk> feel like they are device classes again, which links
>back to the idea about expressing desired device classes in patch 2.
>

Yes, that would look better.

>> +  </features>
>> +
>> +  <!--
>> +      these are flags that are required for this workload to run the best, there
>> +      might be removal of flags as well, maybe
>> +  -->
>> +  <cpu>
>> +    <flag>invtsc</flag>
>> +    <flag>rdtscp</flag>
>> +  </cpu>
>
>Again this works for an x86 only profile, but if we want to support
>many arches, how shoudl we deal with it ?  Separate workload profile
>for each arch, or express info for all arches in one file. Libosinfo
>has tended todo the latter in the past
>

How about something like:

<cpu>
  <flags arch='x86_64'>
    <flag>invtsc</flag>
    <flag>rdtscp</flag>
  </flags>
</cpu>

Replacing the strings with cpuid leaf and bit masks is probably too much, right?

>> +
>> +</libosinfo>
>
>
>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 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20181123/6a7b5596/attachment.sig>