[Libosinfo] [osinfo-db PATCH 3/3] workload: Example for particular use case - SAP HANA
Daniel P. Berrangé
berrange at redhat.com
Tue Nov 20 15:59:19 UTC 2018
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 :|
More information about the Libosinfo
mailing list