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@xxxxxxxxxx> > --- > 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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
