[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180402081806.GA24954@andestech.com>
Date: Mon, 2 Apr 2018 16:18:06 +0800
From: Alan Kao <alankao@...estech.com>
To: Alex Solomatnikov <sols@...ive.com>
CC: Nick Hu <nickhu@...estech.com>, Jonathan Corbet <corbet@....net>,
"Peter Zijlstra" <peterz@...radead.org>,
Palmer Dabbelt <palmer@...ive.com>,
<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
"Arnaldo Carvalho de Melo" <acme@...nel.org>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
"Albert Ou" <albert@...ive.com>,
Namhyung Kim <namhyung@...nel.org>,
<linux-riscv@...ts.infradead.org>, Jiri Olsa <jolsa@...hat.com>,
Greentime Hu <greentime@...estech.com>
Subject: Re: [PATCH 1/2] perf: riscv: preliminary RISC-V support
Hi Alex,
On Mon, Apr 02, 2018 at 03:36:12PM +0800, Alan Kao wrote:
> On Sat, Mar 31, 2018 at 03:47:10PM -0700, Alex Solomatnikov wrote:
>
> The original guess was that maybe, an counter value on a hart is picked
> as the minusend, and an old counter value on another hart was recorded
> as the subtrahend but numerically larger. Then, the overflow causes
> by that subtraction. Please let me name this guess as
> "cross-hart subtraction."
>
> > You can add a skew between cores in qemu, something like this:
> >
> > case CSR_INSTRET:
> > core_id()*return cpu_get_host_ticks()/10;
> > break;
> > case CSR_CYCLE:
> > return cpu_get_host_ticks();
> > break;
> >
>
> However, I tried similar stuff to reproduce the phenomenon but in vain.
> It seems that the
>
> ***cross-hart subtration doesn't even happen, because generic
> code handles them. ...
I am sorry that this observation is wrong. With appropriate tweak, we
successfully reproduce the behavior and locate the the bug.
This will be fix in v2.
Thanks for the helps.
Alan
Powered by blists - more mailing lists