[PATCH 0/5] Misc changes to xentrace_format

[PATCH 0/5] Misc changes to xentrace_format

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

Make xentrace_format more convinient and up to date in usage.

Andrii Anisov (5):
  xentrace_format: print timestamps in nanoseconds
  xentrace_format: switch mhz option to float
  xentrace_format: combine 64-bit LE values from traces
  formats: allign trace record format to the current code
  formats: print time values as decimals

 tools/xentrace/formats         |  6 +++---
 tools/xentrace/xentrace_format | 35 +++++++++++++++++++++++++++--------
 2 files changed, 30 insertions(+), 11 deletions(-)

-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 tools/xentrace/xentrace_format | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format
index 5ff85ae..323d0c2 100644
--- a/tools/xentrace/xentrace_format
+++ b/tools/xentrace/xentrace_format
@@ -8,7 +8,11 @@ import re, sys, string, signal, struct, os, getopt
 
 def usage():
     print >> sys.stderr, \
-          "Usage: " + sys.argv[0] + """ defs-file
+          "Usage: " + sys.argv[0] + """ [-c mhz] defs-file
+               -c mhz   optional time stamps values generator frequency in
+                        MHz. If specified, timestamps are shown in ns,
+                        otherwise in cycles.
+
           Parses trace data in binary format, as output by Xentrace and
           reformats it according to the rules in a file of definitions.  The
           rules in this file should have the format ({ and } show grouping
@@ -223,7 +227,7 @@ while not interrupted:
             last_tsc[cpu] = tsc
 
         if mhz:
-            tsc = tsc / (mhz*1000000.0)
+            tsc = tsc * 1000.0 / mhz
 
         args = {'cpu'   : cpu,
                 'tsc'   : tsc,
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 2/5] xentrace_format: switch mhz option to float

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

In some systems fraction of the MHz might be a meaningful part
of the cycles frequency value. So accept MHz value as float.

Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 tools/xentrace/xentrace_format | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format
index 323d0c2..cae7d34 100644
--- a/tools/xentrace/xentrace_format
+++ b/tools/xentrace/xentrace_format
@@ -11,7 +11,7 @@ def usage():
           "Usage: " + sys.argv[0] + """ [-c mhz] defs-file
                -c mhz   optional time stamps values generator frequency in
                         MHz. If specified, timestamps are shown in ns,
-                        otherwise in cycles.
+                        otherwise in cycles. Accepts float.
 
           Parses trace data in binary format, as output by Xentrace and
           reformats it according to the rules in a file of definitions.  The
@@ -65,7 +65,7 @@ def sighand(x,y):
 
 ##### Main code
 
-mhz = 0
+mhz = 0.0
 
 if len(sys.argv) < 2:
     usage()
@@ -74,7 +74,7 @@ try:
     opts, arg = getopt.getopt(sys.argv[1:], "c:" )
 
     for opt in opts:
-        if opt[0] == '-c' : mhz = int(opt[1])
+        if opt[0] == '-c' : mhz = float(opt[1])
 
 except getopt.GetoptError:
     usage()
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 3/5] xentrace_format: combine 64-bit LE values from traces

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

In order to be able to print possible 64bit LE values from
trace records, precombine possible variants.

Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 tools/xentrace/xentrace_format | 23 +++++++++++++++++++----
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format
index cae7d34..d989924 100644
--- a/tools/xentrace/xentrace_format
+++ b/tools/xentrace/xentrace_format
@@ -26,9 +26,11 @@ def usage():
             will output in hexadecimal and 'o' will output in octal ]
 
           Which correspond to the CPU number, event ID, timestamp counter and
-          the 7 data fields from the trace record.  There should be one such
-          rule for each type of event.
-          
+          the 7 data fields from the trace record. Also combined 64bit LE
+          fields are available. E.g. %(21)d is a decimal representation of a
+          64bit LE value placed as the first element of the trace record.
+          There should be one such rule for each type of event.
+
           Depending on your system and the volume of trace buffer data,
           this script may not be able to keep up with the output of xentrace
           if it is piped directly.  In these circumstances you should have
@@ -185,6 +187,13 @@ while not interrupted:
                 break
             (d1, d2, d3, d4, d5, d6, d7) = struct.unpack(D7REC, line)
 
+        d21 = (d2 << 32) | (0x00000000ffffffff & d1)
+        d32 = (d3 << 32) | (0x00000000ffffffff & d2)
+        d43 = (d4 << 32) | (0x00000000ffffffff & d3)
+        d54 = (d5 << 32) | (0x00000000ffffffff & d4)
+        d65 = (d6 << 32) | (0x00000000ffffffff & d5)
+        d76 = (d7 << 32) | (0x00000000ffffffff & d6)
+
         # Event field is 28bit of 'uint32_t' in header, not 'long'.
         event &= 0x0fffffff
         if event == 0x1f003:
@@ -239,7 +248,13 @@ while not interrupted:
                 '4'     : d4,
                 '5'     : d5,
                 '6'     : d6,
-                '7'     : d7    }
+                '7'     : d7,
+                '21'    : d21,
+                '32'    : d32,
+                '43'    : d43,
+                '54'    : d54,
+                '65'    : d65,
+                '76'    : d76    }
 
         try:
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 4/5] formats: allign trace record format to the current code

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

Allign rtds:repl_budget trace record format to the current code.

Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 tools/xentrace/formats | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index d6e7e3f..7db6d49 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -75,7 +75,7 @@
 0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle        [ cpu = %(1)d ]
 0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick     [ dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
 0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu = 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
-0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
+0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu = 0x%(1)08x, priority_level = %(2)d, cur_deadline = 0x%(4)08x%(3)08x, cur_budget = 0x%(6)08x%(5)08x ]
 0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
 0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule      [ cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

[PATCH 5/5] formats: print time values as decimals

[Andrii Anisov]

From: Andrii Anisov <andrii_anisov@epam.com>

For convinience, print RTDS budget and deadline values as decimals.

Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
---
 tools/xentrace/formats | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/tools/xentrace/formats b/tools/xentrace/formats
index 7db6d49..cf25ab0 100644
--- a/tools/xentrace/formats
+++ b/tools/xentrace/formats
@@ -73,9 +73,9 @@
 0x00022216  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_cand_chk  [ dom:vcpu = 0x%(1)08x ]
 
 0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle        [ cpu = %(1)d ]
-0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick     [ dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
-0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu = 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
-0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu = 0x%(1)08x, priority_level = %(2)d, cur_deadline = 0x%(4)08x%(3)08x, cur_budget = 0x%(6)08x%(5)08x ]
+0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick     [ dom:vcpu = 0x%(1)08x, cur_deadline = %(32)20d, cur_budget = %(54)20d ]
+0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu = 0x%(1)08x, cur_budget = %(32)20d, delta = %(4)d ]
+0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu = 0x%(1)08x, priority_level = %(2)d, cur_deadline = %(43)20d, cur_budget = %(65)20d ]
 0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
 0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule      [ cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
 
-- 
2.7.4


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[George Dunlap]

On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>

The title here makes it seem like you're introducing new functionality,
when in fact you're just documenting and tweaking existing functionality.

The description should be something like:

---
xentrace_format: Document -c option (change timestamps to seconds)

xentrace_format already has an option to set a cpu processor speed by
which to interpret the tsc values.  Document it.

While here, change the formula for this calculation so that <reason here>.
---

Which of course leads me to...

> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
> ---
>  tools/xentrace/xentrace_format | 8 ++++++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/xentrace/xentrace_format b/tools/xentrace/xentrace_format
> index 5ff85ae..323d0c2 100644
> --- a/tools/xentrace/xentrace_format
> +++ b/tools/xentrace/xentrace_format
> @@ -8,7 +8,11 @@ import re, sys, string, signal, struct, os, getopt
>  
>  def usage():
>      print >> sys.stderr, \
> -          "Usage: " + sys.argv[0] + """ defs-file
> +          "Usage: " + sys.argv[0] + """ [-c mhz] defs-file
> +               -c mhz   optional time stamps values generator frequency in
> +                        MHz. If specified, timestamps are shown in ns,
> +                        otherwise in cycles.
> +
>            Parses trace data in binary format, as output by Xentrace and
>            reformats it according to the rules in a file of definitions.  The
>            rules in this file should have the format ({ and } show grouping
> @@ -223,7 +227,7 @@ while not interrupted:
>              last_tsc[cpu] = tsc
>  
>          if mhz:
> -            tsc = tsc / (mhz*1000000.0)
> +            tsc = tsc * 1000.0 / mhz

Why do you prefer this?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 2/5] xentrace_format: switch mhz option to float

[George Dunlap]

On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> In some systems fraction of the MHz might be a meaningful part
> of the cycles frequency value. So accept MHz value as float.
> 
> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>

Acked-by: George Dunlap <george.dunlap@citrix.com>

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[Andrii Anisov]

Hello George,


On 11.09.18 13:15, George Dunlap wrote:
>>           if mhz:
>> -            tsc = tsc / (mhz*1000000.0)
>> +            tsc = tsc * 1000.0 / mhz
> Why do you prefer this?
I'm playing with scheduling from one hand, so time stamps in seconds 
does not give understanding about what's going on.
 From other hand I'm quite confused about how useful timestamps in 
seconds could be for traces. As per my understanding, tracer should be 
useful for debugging some rapidly changing processes.

-- 

*Andrii Anisov*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 5/5] formats: print time values as decimals

[George Dunlap]

On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> For convinience, print RTDS budget and deadline values as decimals.
> 
> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>

Acked-by: George Dunlap <george.dunlap@citrix.com>

> ---
>  tools/xentrace/formats | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/tools/xentrace/formats b/tools/xentrace/formats
> index 7db6d49..cf25ab0 100644
> --- a/tools/xentrace/formats
> +++ b/tools/xentrace/formats
> @@ -73,9 +73,9 @@
>  0x00022216  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  csched2:runq_cand_chk  [ dom:vcpu = 0x%(1)08x ]
>  
>  0x00022801  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:tickle        [ cpu = %(1)d ]
> -0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick     [ dom:vcpu = 0x%(1)08x, cur_deadline = 0x%(3)08x%(2)08x, cur_budget = 0x%(5)08x%(4)08x ]
> -0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu = 0x%(1)08x, cur_budget = 0x%(3)08x%(2)08x, delta = %(4)d ]
> -0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu = 0x%(1)08x, priority_level = %(2)d, cur_deadline = 0x%(4)08x%(3)08x, cur_budget = 0x%(6)08x%(5)08x ]
> +0x00022802  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:runq_pick     [ dom:vcpu = 0x%(1)08x, cur_deadline = %(32)20d, cur_budget = %(54)20d ]
> +0x00022803  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:burn_budget   [ dom:vcpu = 0x%(1)08x, cur_budget = %(32)20d, delta = %(4)d ]
> +0x00022804  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:repl_budget   [ dom:vcpu = 0x%(1)08x, priority_level = %(2)d, cur_deadline = %(43)20d, cur_budget = %(65)20d ]
>  0x00022805  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:sched_tasklet
>  0x00022806  CPU%(cpu)d  %(tsc)d (+%(reltsc)8d)  rtds:schedule      [ cpu[16]:tasklet[8]:idle[4]:tickled[4] = %(1)08x ]
>  
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[George Dunlap]

On 09/11/2018 11:32 AM, Andrii Anisov wrote:
> Hello George,
> 
> 
> On 11.09.18 13:15, George Dunlap wrote:
>>>           if mhz:
>>> -            tsc = tsc / (mhz*1000000.0)
>>> +            tsc = tsc * 1000.0 / mhz
>> Why do you prefer this?
> I'm playing with scheduling from one hand, so time stamps in seconds
> does not give understanding about what's going on.
> From other hand I'm quite confused about how useful timestamps in
> seconds could be for traces. As per my understanding, tracer should be
> useful for debugging some rapidly changing processes.

Oh, sorry -- I missed the point of this patch.

---
xentrace_format: print timestamps in nanoseconds

...rather than seconds.  Having timestamps for rapidly-occurring events
in nanoseconds makes it easier to understand what's going on.

While here, document the -c option.
---

What I do in xenalyze is to have the timestamps in seconds, but always
print down to the nanosecond.  (For this I actually break cpu cycles
into s and ns separately, and then print "%u.%09u".)

But this is also fine with me.

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[George Dunlap]

On 09/11/2018 11:44 AM, George Dunlap wrote:
> On 09/11/2018 11:32 AM, Andrii Anisov wrote:
>> Hello George,
>>
>>
>> On 11.09.18 13:15, George Dunlap wrote:
>>>>           if mhz:
>>>> -            tsc = tsc / (mhz*1000000.0)
>>>> +            tsc = tsc * 1000.0 / mhz
>>> Why do you prefer this?
>> I'm playing with scheduling from one hand, so time stamps in seconds
>> does not give understanding about what's going on.
>> From other hand I'm quite confused about how useful timestamps in
>> seconds could be for traces. As per my understanding, tracer should be
>> useful for debugging some rapidly changing processes.
> 
> Oh, sorry -- I missed the point of this patch.
> 
> ---
> xentrace_format: print timestamps in nanoseconds
> 
> ...rather than seconds.

This should rather say, "..rather than seconds, when the clock speed is
specified."

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 3/5] xentrace_format: combine 64-bit LE values from traces

[George Dunlap]

On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> In order to be able to print possible 64bit LE values from
> trace records, precombine possible variants.

I like the idea; but what does 'LE' mean in this context?

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 4/5] formats: allign trace record format to the current code

[George Dunlap]

I'll let Dario review this one; one comment:

On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> Allign rtds:repl_budget trace record format to the current code.

s/allign/align/g;

Otherwise:

Reviewed-by: George Dunlap <george.dunlap@citrix.com>

 -G

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 3/5] xentrace_format: combine 64-bit LE values from traces

[Andrii Anisov]

Hello George,


On 11.09.18 13:48, George Dunlap wrote:
> I like the idea; but what does 'LE' mean in this context?
Little endian. Most significant 32bit word is at a higher index in the 
array.

-- 

*Andrii Anisov*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[Andrii Anisov]

On 11.09.18 13:44, George Dunlap wrote:
> What I do in xenalyze is to have the timestamps in seconds, but always
> print down to the nanosecond.  (For this I actually break cpu cycles
> into s and ns separately, and then print "%u.%09u".)
Here, we can have the same. With the 0current formula in 
xentrace_format, but changing `%(tsc)d` to `%(tsc).9f` in formats.
BTW, I've just noticed, that reltsc is allways in cycles. And it seems 
odd, as well.

-- 

*Andrii Anisov*


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[George Dunlap]

On 09/11/2018 04:19 PM, Andrii Anisov wrote:
> 
> On 11.09.18 13:44, George Dunlap wrote:
>> What I do in xenalyze is to have the timestamps in seconds, but always
>> print down to the nanosecond.  (For this I actually break cpu cycles
>> into s and ns separately, and then print "%u.%09u".)
> Here, we can have the same. With the 0current formula in
> xentrace_format, but changing `%(tsc)d` to `%(tsc).9f` in formats.
> BTW, I've just noticed, that reltsc is allways in cycles. And it seems
> odd, as well.

FYI, I never use xentrace_format; as far as I'm concerned it's been made
obsolete by xenalyze, and if it were up to me I'd remove it from the
tree.  Lots of people seem to find it useful, so I review patches.  But
I really care very little about what its functionality ends up being.

So feel free to propose whatever patches you want; I have very little
opinion, as long as it keeps working. :-)

 -George

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1602 bytes --]

On Tue, 2018-09-11 at 16:54 +0100, George Dunlap wrote:
> On 09/11/2018 04:19 PM, Andrii Anisov wrote:
> > 
> > On 11.09.18 13:44, George Dunlap wrote:
> > > What I do in xenalyze is to have the timestamps in seconds, but
> > > always
> > > print down to the nanosecond.  (For this I actually break cpu
> > > cycles
> > > into s and ns separately, and then print "%u.%09u".)
> > 
> > Here, we can have the same. With the 0current formula in
> > xentrace_format, but changing `%(tsc)d` to `%(tsc).9f` in formats.
> > 
Sorry, I'm not sure I'm getting this properly. When you say "with the
current formula", do you mean before or after this series?

IAC, changing the default format file that we ship so that it prints
time in the format seconds.nanoseconds (if CPU speed is specified),
would be nice IMO.

> FYI, I never use xentrace_format; as far as I'm concerned it's been
> made
> obsolete by xenalyze, and if it were up to me I'd remove it from the
> tree.  Lots of people seem to find it useful, so I review patches.
>
I almost entirely concur. As said already, the one reason why I think
it still could be useful, and we should keep it, is that the way a
trace will look like can be changed or tweaked rather easily, and
without having to recompile anything, via the formats file, which is
rather cool. :-)

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 3/5] xentrace_format: combine 64-bit LE values from traces

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 675 bytes --]

On Tue, 2018-09-11 at 15:23 +0300, Andrii Anisov wrote:
> Hello George,
> 
> 
> On 11.09.18 13:48, George Dunlap wrote:
> > I like the idea; but what does 'LE' mean in this context?
> 
> Little endian. Most significant 32bit word is at a higher index in
> the 
> array.
>
I did get it, but it took it a little bit, and a couple of re-reads. I
guess, just use 'little endian' (both in changelog and in the code)?

Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 4/5] formats: allign trace record format to the current code

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 606 bytes --]

On Mon, 2018-09-10 at 19:41 +0300, Andrii Anisov wrote:
> From: Andrii Anisov <andrii_anisov@epam.com>
> 
> Allign rtds:repl_budget trace record format to the current code.
> 
Right.

This is (most likely) my fault. Sorry :-P

> Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
>
Reviewed-by: Dario Faggioli <dfaggioli@suse.com>

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 5/5] formats: print time values as decimals

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1043 bytes --]

On Tue, 2018-09-11 at 11:33 +0100, George Dunlap wrote:
> On 09/10/2018 05:41 PM, Andrii Anisov wrote:
> > From: Andrii Anisov <andrii_anisov@epam.com>
> > 
> > For convinience, print RTDS budget and deadline values as decimals.
> > 
I agree, this is a lot better.

> > Signed-off-by: Andrii Anisov <andrii_anisov@epam.com>
> 
> Acked-by: George Dunlap <george.dunlap@citrix.com>
> 
Not strictly necessary, I now. Still:

Reviewed-by: Dario Faggioli <dfaggioli@suse.com>

Andrii, if you decide to make the patch that turns timestamps into
secs.nsecs, can we also convert these to such format (again, in case we
have MHz)?

Or, in general, what I think would be useful, is to have the timestamps
and the scheduling parameters in the same domain (when possible).

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[Andrii Anisov]

Hello Dario,


On 12.09.18 10:42, Dario Faggioli wrote:
> Sorry, I'm not sure I'm getting this properly. When you say "with the
> current formula", do you mean before or after this series?
I did mean the formula existing before this series.

> IAC, changing the default format file that we ship so that it prints
> time in the format seconds.nanoseconds (if CPU speed is specified),
> would be nice IMO.
On the second though I realized it is quite inconvenient. From the 
formats file we can't distinguish if tsc contains float sec.ns or 
integer cycles. For cycles it will look like following:

    CPU0          1090699305.000000000 (+     336) rtds:tickle        [
    cpu = 0 ]


> As said already, the one reason why I think
> it still could be useful, and we should keep it, is that the way a
> trace will look like can be changed or tweaked rather easily, and
> without having to recompile anything, via the formats file, which is
> rather cool. :-)
+1

-- 

*Andrii Anisov*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 1/5] xentrace_format: print timestamps in nanoseconds

[Andrii Anisov]

Hello George,

On 11.09.18 18:54, George Dunlap wrote:
> FYI, I never use xentrace_format; as far as I'm concerned it's been made
> obsolete by xenalyze, and if it were up to me I'd remove it from the
> tree.  Lots of people seem to find it useful, so I review patches.  But
> I really care very little about what its functionality ends up being.
Anyway, thank you for your review.

-- 

*Andrii Anisov*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 5/5] formats: print time values as decimals

[Andrii Anisov]

On 12.09.18 10:54, Dario Faggioli wrote:
> Reviewed-by: Dario Faggioli <dfaggioli@suse.com>
Thank you.

> Andrii, if you decide to make the patch that turns timestamps into
> secs.nsecs, can we also convert these to such format (again, in case we
> have MHz)?
I plan to do the patch. I'll keep this mind.

> Or, in general, what I think would be useful, is to have the timestamps
> and the scheduling parameters in the same domain (when possible).
As I understand, now we do have among scheduling parameters:
     - credit's tsclice in ms, rlimit in us, migration delay in us
     - rtds'es period and budget in us.

I do not think it worth to add more zeros to those parameters for 
converting them to ns.

IMHO trimming timestamps from ns would not be accepted, as well.

-- 

*Andrii Anisov*



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel

Re: [PATCH 5/5] formats: print time values as decimals

[Dario Faggioli]

[-- Attachment #1.1: Type: text/plain, Size: 1685 bytes --]

On Wed, 2018-09-12 at 20:28 +0300, Andrii Anisov wrote:
> On 12.09.18 10:54, Dario Faggioli wrote:
> > 
> > Or, in general, what I think would be useful, is to have the
> > timestamps
> > and the scheduling parameters in the same domain (when possible).
> 
> As I understand, now we do have among scheduling parameters:
>      - credit's tsclice in ms, rlimit in us, migration delay in us
>      - rtds'es period and budget in us.
> 
> I do not think it worth to add more zeros to those parameters for 
> converting them to ns.
> 
We're still speaking only about printing right? IAC, you're right, me
saying "scheduling parameters" was a bit too generic.

What I care is to be able to, when looking at a trace, compare/relate
the time at which a particular event occurred (i.e., the timestamps)
with budget and absolute deadlines --as far as RTDS is concern-- and
with credits --as far as Credit 1 and 2 are concerned (and also with
remaining cap budget, for Credit2).

In fact, that is what you need to fiddle with, in order to understand
whether events are occurring when they are supposed to.

Those other global and (almost) never changing parameters you're
mentioning, are less of a concern, and we can print it in whatever time
unit we want (as far as it's possible to tell which one).

> IMHO trimming timestamps from ns would not be accepted, as well.
> 
No, let's _not_ do that! :-D

Regards,
Dario
-- 
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Software Engineer @ SUSE https://www.suse.com/

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[-- Attachment #2: Type: text/plain, Size: 157 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel