lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 3 Aug 2020 09:54:23 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     John Garry <john.garry@...wei.com>
Cc:     Namhyung Kim <namhyung@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Mark Rutland <mark.rutland@....com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Jiri Olsa <jolsa@...hat.com>, will@...nel.org,
        linux-arm-kernel@...ts.infradead.org, linuxarm@...wei.com,
        Ian Rogers <irogers@...gle.com>,
        Andi Kleen <ak@...ux.intel.com>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 2/2] perf pmu: Improve CPU core PMU HW event list
 ordering

Em Mon, Aug 03, 2020 at 09:00:06AM +0100, John Garry escreveu:
> On 17/06/2020 13:15, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jun 17, 2020 at 08:31:02PM +0900, Namhyung Kim escreveu:
> > > On Wed, Jun 17, 2020 at 6:06 PM John Garry <john.garry@...wei.com> wrote:
> > > > For perf list, the CPU core PMU HW event ordering is such that not all
> > > > events may will be listed adjacent - consider this example:
> > > >    cstate_pkg/c6-residency/                           [Kernel PMU event]
> > > >    cstate_pkg/c7-residency/                           [Kernel PMU event]

> > > > Signed-off-by: John Garry <john.garry@...wei.com>

> > > Acked-by: Namhyung Kim <namhyung@...nel.org>

> > Thanks a lot, applied.
 
> I'm struggling to understand which branch we should base our development on.
> I don't see these patches in perf/core or linux-next. I saw someone
> mentioned tmp.perf/core as a baseline, but I can't see that branch in
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> 
> Please let me know - it would be useful for any dev during the merge window.

So, I'm now pushing things directly to Linus, but just the tooling part,
the branch to do development on is:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core

At some point I think we'll have a git/perf-tools/perf-tools.git, just
like tip, but for now, please use the one above.

My perf/core in the past was rebaseable, I did changes in it after
publishing, trying to have solid bisectability, since I process patch by
patch doing tests on it when we noticed problems, prior to pushing to
Ingo for tip.

Now I am making perf/core non-rebaseable, I push things there
periodically, tagging what is there with the test results, see:

  https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tag/?h=perf-tools-tests-2020-07-17
  https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tag/?h=perf-tools-tests-2020-07-02

I'll try and tag today's state of that tree, which I did tests already
but since v5.8 was released, I merged it there and will retest and tag
the test results.

The tmp.perf/core one is an experiment in making what I have in my local
tree available for more bleeding edge things that are being done, say in
that metrics effort, etc, but I think I'll stop that, since, as your
message shows, it is causing confusion.

I did this because these tests take quite some time and sometimes I have
to fix things and restart it, rinse, repeat.

So please use:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core

I'll further automate all this so that we have a more regular cadence of
updates to perf/core, say every two days or so.

If you have changes that touch both the kernel and userspace, the kernel
bits need to go via tip, the tooling via the perf tree, that for now
(well, it has been like that for quite a long time) is my tree.

Arch specific kernel bits have been going via the arch trees for quite a
while, I think.

- Arnaldo

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ