All of lore.kernel.org
 help / color / mirror / Atom feed
From: Leo Yan <leo.yan@linaro.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Marc Zyngier <maz@kernel.org>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Will Deacon <will@kernel.org>, John Garry <john.garry@huawei.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Suleiman Souhlal <suleiman@google.com>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv3] perf kvm: add kvm-stat for arm64
Date: Thu, 17 Sep 2020 21:08:54 +0800	[thread overview]
Message-ID: <20200917130854.GG12548@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <20200917110028.GB3049@jagdpanzerIV.localdomain>

Hi Sergey,

On Thu, Sep 17, 2020 at 08:00:28PM +0900, Sergey Senozhatsky wrote:
> On (20/09/17 11:21), Marc Zyngier wrote:
> > > > On Arm64, ftrace tracepoint "kvm_entry" doesn't contain the field "id"
> > > > or field "vcpu_id", thus it always reads out the "id" is 0 and it is
> 
> Right, Leo, I saw that. I put "id", because there is ... well, there is
> nothing we can put there. The trace points on arm64, unlike on s390 or x86,
> don't contain info which can let us map trace-event to vcpu_id (even
> (void *)vcpu would have been rather helpful).
> 
> > > > Essentially, this issue is caused by different archs using different
> > > > format for ftrace event "kvm_entry", on x86 it contains feild
> > > > "vcpu_id" but arm64 only just records "vcpu_pc".
> 
> Exactly. I wish trace-points were less of pain-points.
> 
> So 'perf kvm stat' on arm64 works, but it's not as feature rich as on other
> platforms; at the same it's better than nothing, I suppose.

Agree and I don't want to introduce complexity at here.  So it's fine
for me to merge your patch v4 firstly and later use a new patch set
to support "vcpu_id".

As you might have seen the discussion with Marc for new trace events
with "vcpu_id", another way is to add new trace events with "vcpu_id"
and then enable "perf kvm stat" based on new trace events.

Either way is okay for me; except maintainers have different thinking
for this.

Thanks,
Leo

WARNING: multiple messages have this Message-ID (diff)
From: Leo Yan <leo.yan@linaro.org>
To: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Mathieu Poirier <mathieu.poirier@linaro.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Marc Zyngier <maz@kernel.org>, John Garry <john.garry@huawei.com>,
	linux-kernel@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Suleiman Souhlal <suleiman@google.com>,
	Namhyung Kim <namhyung@kernel.org>, Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv3] perf kvm: add kvm-stat for arm64
Date: Thu, 17 Sep 2020 21:08:54 +0800	[thread overview]
Message-ID: <20200917130854.GG12548@leoy-ThinkPad-X240s> (raw)
In-Reply-To: <20200917110028.GB3049@jagdpanzerIV.localdomain>

Hi Sergey,

On Thu, Sep 17, 2020 at 08:00:28PM +0900, Sergey Senozhatsky wrote:
> On (20/09/17 11:21), Marc Zyngier wrote:
> > > > On Arm64, ftrace tracepoint "kvm_entry" doesn't contain the field "id"
> > > > or field "vcpu_id", thus it always reads out the "id" is 0 and it is
> 
> Right, Leo, I saw that. I put "id", because there is ... well, there is
> nothing we can put there. The trace points on arm64, unlike on s390 or x86,
> don't contain info which can let us map trace-event to vcpu_id (even
> (void *)vcpu would have been rather helpful).
> 
> > > > Essentially, this issue is caused by different archs using different
> > > > format for ftrace event "kvm_entry", on x86 it contains feild
> > > > "vcpu_id" but arm64 only just records "vcpu_pc".
> 
> Exactly. I wish trace-points were less of pain-points.
> 
> So 'perf kvm stat' on arm64 works, but it's not as feature rich as on other
> platforms; at the same it's better than nothing, I suppose.

Agree and I don't want to introduce complexity at here.  So it's fine
for me to merge your patch v4 firstly and later use a new patch set
to support "vcpu_id".

As you might have seen the discussion with Marc for new trace events
with "vcpu_id", another way is to add new trace events with "vcpu_id"
and then enable "perf kvm stat" based on new trace events.

Either way is okay for me; except maintainers have different thinking
for this.

Thanks,
Leo

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-09-17 13:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-17  0:36 [PATCHv3] perf kvm: add kvm-stat for arm64 Sergey Senozhatsky
2020-09-17  0:36 ` Sergey Senozhatsky
2020-09-17  8:47 ` Leo Yan
2020-09-17  8:47   ` Leo Yan
2020-09-17  9:54   ` Sergey Senozhatsky
2020-09-17  9:54     ` Sergey Senozhatsky
2020-09-17 10:09 ` Leo Yan
2020-09-17 10:09   ` Leo Yan
2020-09-17 10:12   ` Leo Yan
2020-09-17 10:12     ` Leo Yan
2020-09-17 10:21     ` Marc Zyngier
2020-09-17 10:21       ` Marc Zyngier
2020-09-17 11:00       ` Sergey Senozhatsky
2020-09-17 11:00         ` Sergey Senozhatsky
2020-09-17 13:08         ` Leo Yan [this message]
2020-09-17 13:08           ` Leo Yan
2020-09-17 11:42       ` Leo Yan
2020-09-17 11:42         ` Leo Yan
2020-09-17 11:53         ` Marc Zyngier
2020-09-17 11:53           ` Marc Zyngier
2020-09-17 12:52           ` Leo Yan
2020-09-17 12:52             ` Leo Yan
2020-09-18  0:32           ` Sergey Senozhatsky
2020-09-18  0:32             ` Sergey Senozhatsky
2020-09-18  8:20             ` Marc Zyngier
2020-09-18  8:20               ` Marc Zyngier
2020-09-18 10:35               ` Sergey Senozhatsky
2020-09-18 10:35                 ` Sergey Senozhatsky
2020-09-18 10:55                 ` Marc Zyngier
2020-09-18 10:55                   ` Marc Zyngier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200917130854.GG12548@leoy-ThinkPad-X240s \
    --to=leo.yan@linaro.org \
    --cc=acme@kernel.org \
    --cc=john.garry@huawei.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mathieu.poirier@linaro.org \
    --cc=maz@kernel.org \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=suleiman@google.com \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.