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

[Daniel P. Berrangé]

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.

> +    <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.

> +  </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

> +
> +</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 :|