[v8,7/7] trace: [trivial] Statically enable all guest events

Commit Message

Emilio Cota June 9, 2017, 2:25 a.m. UTC

From: Lluís Vilanova <[e-mail]>

The optimizations of this series makes it feasible to have them
available on all builds.

Signed-off-by: Lluís Vilanova <[e-mail]>
Signed-off-by: Emilio G. Cota <[e-mail]>
---
 trace-events | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Comments

Daniel P. Berrangé June 26, 2017, 8:28 a.m. UTC | #1

On Thu, Jun 08, 2017 at 10:25:22PM -0400, Emilio G. Cota wrote:
> From: Lluís Vilanova <[e-mail]>
> 
> The optimizations of this series makes it feasible to have them
> available on all builds.

I'm not saying you're wrong, but where is the data to backup this
assertion ?

IMHO, this commit message should be describing how performance was
tested and what the results were.

Regards,
Daniel

Lluís Vilanova June 26, 2017, 9:18 a.m. UTC | #2

Daniel P Berrange writes:

> On Thu, Jun 08, 2017 at 10:25:22PM -0400, Emilio G. Cota wrote:
>> From: Lluís Vilanova <[e-mail]>
>> 
>> The optimizations of this series makes it feasible to have them
>> available on all builds.

> I'm not saying you're wrong, but where is the data to backup this
> assertion ?

> IMHO, this commit message should be describing how performance was
> tested and what the results were.

I can submit a new series with the performance measurements now that you've
informally OK'ed Emilio's new patch.

Is there some public script to automate that or do I have to cook my own?


Thanks,
  Lluis

Daniel P. Berrangé June 26, 2017, 9:26 a.m. UTC | #3

On Mon, Jun 26, 2017 at 12:18:14PM +0300, Lluís Vilanova wrote:
> Daniel P Berrange writes:
> 
> > On Thu, Jun 08, 2017 at 10:25:22PM -0400, Emilio G. Cota wrote:
> >> From: Lluís Vilanova <[e-mail]>
> >> 
> >> The optimizations of this series makes it feasible to have them
> >> available on all builds.
> 
> > I'm not saying you're wrong, but where is the data to backup this
> > assertion ?
> 
> > IMHO, this commit message should be describing how performance was
> > tested and what the results were.
> 
> I can submit a new series with the performance measurements now that you've
> informally OK'ed Emilio's new patch.
> 
> Is there some public script to automate that or do I have to cook my own?

I don't think there's anything standardized in this area.

Regards,
Daniel

Laurent Desnogues June 26, 2017, 9:32 a.m. UTC | #4

On Mon, Jun 26, 2017 at 11:18 AM, Lluís Vilanova <[e-mail]> wrote:
> Daniel P Berrange writes:
>
>> On Thu, Jun 08, 2017 at 10:25:22PM -0400, Emilio G. Cota wrote:
>>> From: Lluís Vilanova <[e-mail]>
>>>
>>> The optimizations of this series makes it feasible to have them
>>> available on all builds.
>
>> I'm not saying you're wrong, but where is the data to backup this
>> assertion ?
>
>> IMHO, this commit message should be describing how performance was
>> tested and what the results were.
>
> I can submit a new series with the performance measurements now that you've
> informally OK'ed Emilio's new patch.
>
> Is there some public script to automate that or do I have to cook my own?

Emilio proposed this for user mode:

https://github.com/cota/dbt-bench

IIRC he also has a Linux image that boots and shutdowns immediately.

Hope this helps,

Laurent

Lluís Vilanova June 26, 2017, 4:22 p.m. UTC | #5

Lluís Vilanova writes:

> Daniel P Berrange writes:
>> On Thu, Jun 08, 2017 at 10:25:22PM -0400, Emilio G. Cota wrote:
>>> From: Lluís Vilanova <[e-mail]>
>>> 
>>> The optimizations of this series makes it feasible to have them
>>> available on all builds.

>> I'm not saying you're wrong, but where is the data to backup this
>> assertion ?

>> IMHO, this commit message should be describing how performance was
>> tested and what the results were.

> I can submit a new series with the performance measurements now that you've
> informally OK'ed Emilio's new patch.

> Is there some public script to automate that or do I have to cook my own?

BTW, I just realized that my original cover for v7 did include results:

  https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02741.html

Do such numbers need to be in this commit or is the cover fine?


Thanks,
  Lluis

Daniel P. Berrangé June 26, 2017, 4:26 p.m. UTC | #6

On Mon, Jun 26, 2017 at 07:22:28PM +0300, Lluís Vilanova wrote:
> Lluís Vilanova writes:
> 
> > Daniel P Berrange writes:
> >> On Thu, Jun 08, 2017 at 10:25:22PM -0400, Emilio G. Cota wrote:
> >>> From: Lluís Vilanova <[e-mail]>
> >>> 
> >>> The optimizations of this series makes it feasible to have them
> >>> available on all builds.
> 
> >> I'm not saying you're wrong, but where is the data to backup this
> >> assertion ?
> 
> >> IMHO, this commit message should be describing how performance was
> >> tested and what the results were.
> 
> > I can submit a new series with the performance measurements now that you've
> > informally OK'ed Emilio's new patch.
> 
> > Is there some public script to automate that or do I have to cook my own?
> 
> BTW, I just realized that my original cover for v7 did include results:
> 
>   https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg02741.html
> 
> Do such numbers need to be in this commit or is the cover fine?

Please do copy that info to the commit message - when someone looks back
at git history in a year's time, they'll have the commit message right
there, but will rarely think to look through the mailing list for a cover
letter with data.

Regards,
Daniel

Patch

diff --git a/trace-events b/trace-events
index d7a4d94..b040d7e 100644
--- a/trace-events
+++ b/trace-events
@@ -125,7 +125,7 @@  vcpu guest_cpu_reset(void)
 #
 # Mode: user, softmmu
 # Targets: TCG(all)
-disable vcpu tcg guest_mem_before(TCGv vaddr, uint8_t info) "info=%d", "vaddr=0x%016"PRIx64" info=%d"
+vcpu tcg guest_mem_before(TCGv vaddr, uint8_t info) "info=%d", "vaddr=0x%016"PRIx64" info=%d"
 
 # @num: System call number.
 # @arg*: System call argument value.
@@ -134,7 +134,7 @@  disable vcpu tcg guest_mem_before(TCGv vaddr, uint8_t info) "info=%d", "vaddr=0x
 #
 # Mode: user
 # Targets: TCG(all)
-disable vcpu guest_user_syscall(uint64_t num, uint64_t arg1, uint64_t arg2, uint64_t arg3, uint64_t arg4, uint64_t arg5, uint64_t arg6, uint64_t arg7, uint64_t arg8) "num=0x%016"PRIx64" arg1=0x%016"PRIx64" arg2=0x%016"PRIx64" arg3=0x%016"PRIx64" arg4=0x%016"PRIx64" arg5=0x%016"PRIx64" arg6=0x%016"PRIx64" arg7=0x%016"PRIx64" arg8=0x%016"PRIx64
+vcpu guest_user_syscall(uint64_t num, uint64_t arg1, uint64_t arg2, uint64_t arg3, uint64_t arg4, uint64_t arg5, uint64_t arg6, uint64_t arg7, uint64_t arg8) "num=0x%016"PRIx64" arg1=0x%016"PRIx64" arg2=0x%016"PRIx64" arg3=0x%016"PRIx64" arg4=0x%016"PRIx64" arg5=0x%016"PRIx64" arg6=0x%016"PRIx64" arg7=0x%016"PRIx64" arg8=0x%016"PRIx64
 
 # @num: System call number.
 # @ret: System call result value.
@@ -143,4 +143,4 @@  disable vcpu guest_user_syscall(uint64_t num, uint64_t arg1, uint64_t arg2, uint
 #
 # Mode: user
 # Targets: TCG(all)
-disable vcpu guest_user_syscall_ret(uint64_t num, uint64_t ret) "num=0x%016"PRIx64" ret=0x%016"PRIx64
+vcpu guest_user_syscall_ret(uint64_t num, uint64_t ret) "num=0x%016"PRIx64" ret=0x%016"PRIx64