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